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/