idnits 2.17.1
draft-brown-versioning-link-relations-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 13, 2009) is 5400 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Brown
3 Internet-Draft G. Clemm
4 Intended status: Informational IBM
5 Expires: January 14, 2010 J. Reschke, Ed.
6 greenbytes
7 July 13, 2009
9 Link Relations for Simple Version Navigation
10 draft-brown-versioning-link-relations-01
12 Status of this Memo
14 This Internet-Draft is submitted to IETF in full conformance with the
15 provisions of BCP 78 and BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on January 14, 2010.
35 Copyright Notice
37 Copyright (c) 2009 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents in effect on the date of
42 publication of this document (http://trustee.ietf.org/license-info).
43 Please review these documents carefully, as they describe your rights
44 and restrictions with respect to this document.
46 Abstract
48 This specification defines Atom link relations for navigation between
49 a resource and its versions.
51 Editorial Note (To be removed by RFC Editor before publication)
53 Please send comments to the Atom Syntax mailing list
54 ().
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Link Relations . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
66 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
67 Appendix A. Relationship to JCR and WebDAV . . . . . . . . . . . . 5
68 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . . 5
69 Appendix C. Change Log (to be removed by RFC Editor before
70 publication) . . . . . . . . . . . . . . . . . . . . . 6
71 C.1. Since draft-brown-link-relations-00 . . . . . . . . . . . . 6
72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
74 1. Introduction
76 This specification defines link relations that may be used on a
77 resource that exists in a system that supports versioning to navigate
78 among the different resources available, such as past versions.
80 2. Terminology
82 The terms below are borrowed from the Versioning Extensions to WebDAV
83 (Web Distributed Authoring and Versioning) ([RFC3253]).
85 Version-Controlled Resource, Checked-Out
87 When a versionable resource is put under version control, it
88 becomes a "version-controlled resource". A version-controlled
89 resource can be "checked out" to allow modification.
91 Checked-Out Resource
93 A "checked-out resource" is a resource under version control that
94 is in the checked-out state.
96 Version Resource
98 A "version resource", or simply "version", is a resource that
99 contains a copy of a particular state of a version-controlled
100 resource. A version is created by "checking in" a checked-out
101 resource. The server allocates a distinct new URL for each new
102 version.
104 Version History Resource
106 A "version history resource", or simply "version history", is a
107 resource that contains all the versions of a particular version-
108 controlled resource.
110 Predecessor, Successor, Ancestor, Descendant
112 When a version-controlled resource is checked out and then
113 subsequently checked in, the version that was checked out becomes
114 a "predecessor" of the version created by the checkin. A client
115 can specify multiple predecessors for a new version if the new
116 version is logically a merge of those predecessors. When a
117 version is connected to another version by traversing one or more
118 predecessor relations, it is called an "ancestor" of that version.
119 The inverse of the predecessor and ancestor relations are the
120 "successor" and "descendant" relations. Therefore, if X is a
121 predecessor of Y, then Y is a successor of X, and if X is an
122 ancestor of Y, then Y is a descendant of X.
124 Root Version Resource
126 The "root version resource", or simply "root version", is the
127 version in a version history that is an ancestor of every other
128 version in that version history.
130 Working Resource
132 A "working resource" is a checked-out resource created by the
133 server at a server-defined URL when a version (instead of a
134 version-controlled resource) is checked out.
135 [[issue.working.resource: Is this true for JCR and CMIS as well?
136 Maybe we need to relax the definition? --jre]]
138 3. Link Relations
140 The following link relations are defined:
142 version-history When included on a version controlled resource, this
143 link points to a resource containing the version history for this
144 resource.
146 latest-version When included on a version controlled resource, this
147 link points to a resource containing the latest (e.g., current)
148 version. [[issue.latest.version: I think "latest" is misleading,
149 as it may not be the "latest" when different branches are
150 involved. JCR 1.0 has "base version", defined as "The base
151 version of a particular node N is the one that will serve as the
152 default immediate predecessor of the next version of N that is
153 created." -- can we adopt that? (see
154 ).
155 --jre]]
157 working-copy When included on a version resource, this link points
158 to a Working Resource.
160 predecessor-version When included on a version resource, this link
161 points to a resource containing the predecessor version in the
162 version history.
164 successor-version When included on a version resource, this link
165 points to a resource containing the successor version in the
166 version history.
168 4. Examples
170 [[anchor2: To Be Done]]
172 5. Security Considerations
174 Automated agents should take care when these relation crosses
175 administrative domains (e.g., the URI has a different authority than
176 the current document).
178 6. IANA Considerations
180 The link relations defined in Section 3 are to be registered by IANA
181 per [RFC4287].
183 All link relations defined in this document will have the following
184 expected display characteristics:
186 Undefined; this relation can be used for background processing or
187 to provide extended functionality without displaying its value.
189 7. References
191 7.1. Normative References
193 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
194 Format", RFC 4287, December 2005.
196 7.2. Informative References
198 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
199 Whitehead, "Versioning Extensions to WebDAV (Web
200 Distributed Authoring and Versioning)", RFC 3253,
201 March 2002.
203 Appendix A. Relationship to JCR and WebDAV
205 [[anchor6: To Be Done: describe how versioning properties in JCR and
206 in WebDAV/DeltaV map to the newly defined link relations.]]
208 Appendix B. Contributors
210 The content and concepts within are a product of the Content
211 Management Interoperability Services (CMIS) Technical Committee (TC)
212 at OASIS.
214 All members of the TC have contributed.
216 Appendix C. Change Log (to be removed by RFC Editor before publication)
218 C.1. Since draft-brown-link-relations-00
220 Added Geoff Clemm as author.
222 Renamed link relation "all-versions" to "version-history". Fixed
223 description of "working-resource" relation to state that it appears
224 on a version resource.
226 Authors' Addresses
228 Al Brown
229 IBM
230 3565 Harbor Blvd
231 Costa Mesa, California 92626
232 US
234 Email: albertcbrown@us.ibm.com
236 Geoffrey Clemm
237 IBM
238 20 Maguire Road
239 Lexington, MA 02421
240 US
242 Email: geoffrey.clemm@us.ibm.com
244 Julian F. Reschke (editor)
245 greenbytes GmbH
246 Hafenweg 16
247 Muenster, NW 48155
248 Germany
250 Email: julian.reschke@greenbytes.de
251 URI: http://greenbytes.de/tech/webdav/