One document matched: draft-brown-versioning-link-relations-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
This XML document is the output of clean-for-DTD.xslt; a tool that strips
extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc
PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-brown-versioning-link-relations-02" category="info">
<front>
<title abbrev="Version Navigation Link Relations">Link Relations for Simple Version Navigation</title>
<author initials="A. B." surname="Brown" fullname="Al Brown">
<organization>IBM</organization>
<address>
<postal>
<street>3565 Harbor Blvd</street>
<city>Costa Mesa</city>
<region>California</region>
<code>92626</code>
<country>US</country>
</postal>
<email>albertcbrown@us.ibm.com</email>
</address>
</author>
<author initials="G." surname="Clemm" fullname="Geoffrey Clemm">
<organization>IBM</organization>
<address>
<postal>
<street>20 Maguire Road</street>
<city>Lexington</city>
<region>MA</region>
<code>02421</code>
<country>US</country>
</postal>
<email>geoffrey.clemm@us.ibm.com</email>
</address>
</author>
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
<organization abbrev="greenbytes">greenbytes GmbH</organization>
<address>
<postal>
<street>Hafenweg 16</street>
<city>Muenster</city>
<region>NW</region>
<code>48155</code>
<country>Germany</country>
</postal>
<email>julian.reschke@greenbytes.de</email>
<uri>http://greenbytes.de/tech/webdav/</uri>
</address>
</author>
<date month="November" year="2009" day="19"/>
<abstract>
<t>
This specification defines Atom link relations for navigation between
a resource and its versions.
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor before publication)">
<t>
Please send comments to the Atom Syntax mailing list
(<eref target="http://www.imc.org/atom-syntax/"/>).
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
This specification defines link relations that may be used on a
resource that exists in a system that supports versioning to navigate
among the different resources available, such as past versions.
</t>
</section>
<section title="Terminology" anchor="terminology">
<t>
<?rfc needLines="4"?>Versioned Resource
<list>
<t>
When a resource is put under version control, it becomes a "versioned
resource". A versioned resource can be "checked out" to allow
modification.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>Version History
<list>
<t>
A "version history" resource is a resource that contains all the
versions of a particular versioned resource.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>Predecessor, Successor
<list>
<t>
When a versioned resource is checked out and then subsequently checked
in, the version that was checked out becomes a "predecessor" of the
version created by the checkin. A client can specify multiple
predecessors for a new version if the new version is logically a merge of
those predecessors. The inverse of the predecessor relation is the
"successor" relation. Therefore, if X is a predecessor of Y, then Y is a
successor of X.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>Working Copy
<list>
<t>
A "working copy" is a resource at a server-defined URL that can be
modified to create a new version of a versioned resource.
</t>
</list>
</t>
</section>
<section title="Link Relations" anchor="linkrelations">
<t>
The following link relations are defined:
</t>
<t>
<?rfc needLines="4"?>version-history
<list>
<t>
When included on a versioned resource, this link points to a resource
containing the version history for this resource.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>latest-version
<list>
<t>
When included on a versioned resource, this link points to a resource
containing the latest (e.g., current) version.
</t>
<t>
The latest version is defined by the system. For linear versioning
systems, this is probably the latest version by timestamp. For systems
that support branching, there will be multiple latest versions, one for
each branch in the version history.
</t>
<t>
Some systems may allow multiple of these link relations.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>working-copy
<list>
<t>
When included on a versioned resource, this link points to a working copy
for this resource.
</t>
<t>
Some systems may allow multiple of these link relations.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>predecessor-version
<list>
<t>
When included on a versioned resource, this link points to a resource
containing the predecessor version in the version history.
</t>
<t>
Some systems may allow multiple of these link relations in the case of a
multiple branches merging.
</t>
</list>
</t>
<t>
<?rfc needLines="4"?>successor-version
<list>
<t>
When included on a versioned resource, this link points to a resource
containing the successor version in the version history.
</t>
<t>
Some systems may allow multiple of these link relations in order to
support branching.
</t>
</list>
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
Automated agents should take care when these relation
crosses administrative domains (e.g., the URI has a different
authority than the current document).
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
The link relations defined in <xref target="linkrelations"/>
are to be registered by IANA per
<xref target="RFC4287"/>.
<cref source="jre" anchor="lhdraft">Will be updated to follow [draft-nottingham-http-link-header] once approved by the IESG.</cref>
</t>
<t>
All link relations defined in this document will have the following
expected display characteristics:
<list>
<t>
Undefined; this relation can be used for background processing or to provide
extended functionality without displaying its value.
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC4287">
<front>
<title>The Atom Syndication Format</title>
<author fullname="M. Nottingham" surname="Nottingham" initials="M.">
<organization/>
</author>
<author fullname="R. Sayre" surname="Sayre" initials="R.">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4287"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3253">
<front>
<title>Versioning Extensions to WebDAV (Web Distributed
Authoring and Versioning)</title>
<author fullname="G. Clemm" surname="Clemm" initials="G.">
<organization>Rational Software (IBM)</organization>
</author>
<author fullname="J. Amsden" surname="Amsden" initials="J.">
<organization/>
</author>
<author fullname="T. Ellison" surname="Ellison" initials="T.">
<organization>IBM</organization>
</author>
<author fullname="C. Kaler" surname="Kaler" initials="C.">
<organization>Microsoft</organization>
</author>
<author fullname="J. Whitehead" surname="Whitehead" initials="J.">
<organization>U.C. Santa Cruz</organization>
</author>
<date month="March" year="2002"/>
</front>
<seriesInfo name="RFC" value="3253"/>
</reference>
<reference anchor="JSR-283" target="http://www.day.com/specs/jcr/2.0/">
<front>
<title>Content Repository API for Java™ Technology Specification</title>
<author>
<organization>Day Software</organization>
</author>
<author fullname="David Nuescheler" surname="Nuescheler" initials="D.">
<organization>Day Software</organization>
</author>
<author fullname="Peeter Piegaze" surname="Piegaze" initials="P.">
<organization>Day Software</organization>
</author>
<date month="August" year="2009"/>
</front>
<seriesInfo name="Java Specification Request" value="283"/>
</reference>
<reference anchor="draft-nottingham-http-link-header">
<front>
<title>Web Linking</title>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham">
<organization/>
<address>
<email>mnot@mnot.net</email>
<uri>http://www.mnot.net/</uri>
</address>
</author>
<date year="2009" month="July"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-nottingham-http-link-header-06"/>
</reference>
</references>
<section title="Relationship to Java Content Repository (JCR) and WebDAV">
<t>
The link relations defined in <xref target="linkrelations"/> correspond to
various properties used in WebDAV Versioning <xref target="RFC3253"/>
and JCR <xref target="JSR-283"/>:
</t>
<t>
version-history
</t>
<t>
<list>
<t>
WebDAV: the resource identified by the DAV:version-history property
(<xref target="RFC3253"/>, Sections 5.2.1 and 5.3.1).
</t>
<t>
JCR: the node identified by jcr:versionHistory
property (<xref target="JSR-283"/>, Section 3.13.2.4) for
versionable nodes, the parent folder for version nodes.
</t>
</list>
</t>
<t>
latest-version
</t>
<t>
<list>
<t>
WebDAV: for version-controlled resources, DAV:checked-in (<xref target="RFC3253"/>, Section 3.2.1) or
DAV:checked-out (<xref target="RFC3253"/>, Section 3.3.1), depending
on checkin state. For version resources, a successor version that itself does
not have any successors.
</t>
<t>
JCR: the version node identified by the jcr:baseVersion property (<xref target="JSR-283"/>, Section 3.13.2.5)
for versionable nodes; for version nodes, a successor version that itself does
not have any successors.
</t>
</list>
</t>
<t>
working-resource
</t>
<t>
<list>
<t>
WebDAV: for version-controlled resources that are checked-out in place: the
resource itself. For version resources: each resource identified by a member
of the DAV:checkout-set property (see <xref target="RFC3253"/>, Section 3.4.3).
</t>
<t>
JCR: for checked-out versionable nodes: the node itself.
</t>
</list>
</t>
<t>
predecessor-version
</t>
<t>
<list>
<t>
WebDAV: each resource identified by a member of DAV:predecessor-set (<xref target="RFC3253"/>, Sections 3.3.2 and 3.4.1).
</t>
<t>
JCR: each node identified by a member of jcr:predecessors (<xref target="JSR-283"/>, Section 3.13.3.3).
</t>
</list>
</t>
<t>
successor-version
</t>
<t>
<list>
<t>
WebDAV: each resource identified by a member of DAV:successor-set (<xref target="RFC3253"/>, Section 3.4.2).
</t>
<t>
JCR: each node identified by a member of jcr:successors (<xref target="JSR-283"/>, Section 3.13.3.4).
</t>
</list>
</t>
<section title="Example: Use of Link Relations in HTTP Link Header">
<t>
The "Web Linking" specification (<xref target="draft-nottingham-http-link-header"/>)
generalizes Atom link relations, and also re-introduces the HTTP "Link"
header as a way to expose link relations in HTTP responses. This will make
it possible to expose version links independently from a specific vocabulary,
be it the Atom Feed Format (<xref target="RFC4287"/>) or WebDAV properties
(<xref target="RFC3253"/>).
</t>
<t>
For instance, a response to an VERSION-CONTROL request (<xref target="RFC3253"/>, Section 3.5) could
expose newly created version-history and checked-in version as link relations:
</t>
<figure><preamble>
>> Request:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
VERSION-CONTROL /docs/test.txt HTTP/1.1
Host: example.net
]]></artwork></figure>
<figure><preamble>
>> Response:</preamble>
<artwork type="message/http; msgtype="response""><![CDATA[
HTTP/1.1 200 OK
Link: </system/v/84345634/1>; rel=latest-version;
anchor=</docs/test.txt>
Link: </system/vh/84345634>; rel=version-history;
anchor=</docs/test.txt>
]]></artwork>
<postamble>(Note that in this case, the anchor parameter is used, as the
response to a VERSION-CONTROL request is not a representation of the resource
at the Request-URI)</postamble>
</figure>
<t>
A subsequent HEAD request on that resource could expose the version-history
and latest-version relations as well:
</t>
<figure><preamble>
>> Request:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
HEAD /docs/test.txt HTTP/1.1
Host: example.net
]]></artwork></figure>
<figure><preamble>
>> Response:</preamble>
<artwork type="message/http; msgtype="response""><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 12345
Link: </system/v/84345634/1>; rel=latest-version
Link: </system/vh/84345634>; rel=version-history
]]></artwork></figure>
<t>
After creating more versions, following the latest-version would then expose
predecessors of a version:
</t>
<figure><preamble>
>> Request:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
HEAD /system/v/84345634/3 HTTP/1.1
Host: example.net
]]></artwork></figure>
<figure><preamble>
>> Response:</preamble>
<artwork type="message/http; msgtype="response""><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 12323
Link: </system/v/84345634/2>; rel=predecessor-version
]]></artwork></figure>
</section>
</section>
<section title="Contributors" anchor="contributors">
<t>
The content and concepts within are a product of the Content Management
Interoperability Services (CMIS) Technical Committee (TC) at OASIS.
</t>
<t>
All members of the TC have contributed.
</t>
</section>
<section title="Change Log (to be removed by RFC Editor before publication)" anchor="changes">
<section title="Since draft-brown-link-relations-00">
<t>
Added Geoff Clemm as author.
</t>
<t>
Renamed link relation "all-versions" to "version-history". Fixed
description of "working-resource" relation to state that it appears
on a version resource.
</t>
</section>
<section title="Since draft-brown-link-relations-01">
<t>
Rewrite terminology and link relations using simpler definitions
that can reflect versioning approaches different from WebDAV.
</t>
<t>
Add JCR/WebDAV property table. And reference to Web Linking draft
(for now informative) and examples showing use of the Link header.
</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:18:39 |