idnits 2.17.1 draft-reschke-deltav-compute-checkin-uri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC3253]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2518' is defined on line 310, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. F. Reschke 3 Internet Draft greenbytes 4 Expires: September 2002 March 2002 6 Computing the CHECKIN URI in WebDAV versioning 7 draft-reschke-deltav-compute-checkin-uri-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire in September 2002. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 In many cases, a versioning-aware client might want to 37 display/include the URI of the version it's editing while it's being 38 edited. For instance, an editor might include this as meta 39 information, or the author of a document might want to know the URI 40 of the version before it's checked in. A well-known example is the 41 W3C way of referring to document versions in recommendations: it 42 contains references to "the current version", to "this version" and 43 to the "previous version". Something like this is currently 44 impossible with WebDAV deltaV [RFC3253], as the version URI is 45 determined at the time of CHECKIN. 47 Distribution of this document is unlimited. Please send comments to 48 the WebDAV versioning (delta-V) working group at ietf-dav- 49 versioning@w3.org, which may be joined by sending a message with 50 subject "subscribe" to ietf-dav-versioning-request@w3.org. 52 Discussions of the delta-V working group are archived at URL: 53 http://lists.w3.org/Archives/Public/ietf-dav-versioning/. 55 Table of Contents 57 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 58 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1 Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 60 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3 Changes for CHECKOUT method (when applied to a version- 62 controlled resource) . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1 Example for successful CHECKOUT with computed version URI 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2 Example for successful CHECKOUT without computed version 66 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4 Changes for CHECKIN method (when applied to a version- 68 controlled resource) . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1 Example for successful CHECKIN with computed version URI . 9 70 4.2 Example for failed CHECKIN with computed version URI . . . 10 71 5 Compatibility Considerations . . . . . . . . . . . . . . . . . 11 72 6 Internationalization Considerations . . . . . . . . . . . . . . 12 73 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 74 8 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 15 76 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 78 A Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 A.1 Since 'draft-reschke-deltav-compute-checkin-uri-00' . . . . 17 81 1 Notational Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2 Introduction 89 In many cases, a versioning-aware client might want to 90 display/include the URI of the version it's editing while it's being 91 edited. For instance, an editor might include this as meta 92 information, or the author of a document might want to know the URI 93 of the version before it's checked in. A well-known example is the 94 W3C way of referring to document versions in recommendations: it 95 contains references to "the current version", to "this version" and 96 to the "previous version". Something like this is currently 97 impossible with WebDAV deltaV [RFC3253], as the version URI is 98 determined at the time of CHECKIN. 100 This specification builds on the infrastructure provided by the 101 WebDAV Versioning Protocol, adding support for servers willing to 102 compute an "expected version URI" upon CHECKOUT, and using this URI 103 at time of CHECKIN. 105 This document defines an extension element that could ultimately 106 become part of the WebDAV deltaV protocol. Being just an individual 107 submission, it currently defines it in the proprietary namespace 109 http://sapportals.com/xmlns/cm/webdav 111 instead of the "DAV:" namespace. It uses a prefix of "cu:" for 112 referring to elements in this namespace. However, WebDAV server and 113 clients are free to use any prefix, provided that there is a 114 namespace declaration that binds the prefix to the URI of the same 115 namespace. 117 3 Changes for CHECKOUT method (when applied to a version-controlled 118 resource) 120 A client may ask for an "expected version URI" upon CHECKOUT. This is 121 done by placing cu:compute-expected-version-URI as top-level element 122 into the request body. The server is free to either ignore the 123 request, or to return it's best guess about what the URI for a 124 version resource created upon CHECKIN would be. 126 The client can detect the "expected version URI" by parsing the 127 response body for a top-level element called cu:expected-version-URI. 129 3.1 Example for successful CHECKOUT with computed version URI 131 >>Request 133 CHECKOUT /foo.html HTTP/1.1 134 Host: www.webdav.org 135 Content-Type: text/xml; charset="utf-8" 136 Content-Length: xxxx 138 139 141 142 144 >>Response 146 HTTP/1.1 200 OK 147 Cache-Control: no-cache 148 Content-Type: text/xml; charset="utf-8" 149 Content-Length: xxxx 151 152 154 http://repo.webdav.org/his/23/ver/32 156 157 In this example, the server was able to compute the "expected version 158 URI" and returned it in the cu:expected-version-URI element. 160 3.2 Example for successful CHECKOUT without computed version URI 162 >>Request 164 CHECKOUT /foo.html HTTP/1.1 165 Host: www.webdav.org 166 Content-Type: text/xml; charset="utf-8" 167 Content-Length: xxxx 169 170 172 173 175 >>Response 177 HTTP/1.1 200 OK 178 Cache-Control: no-cache 180 In this case, no response body was returned, and thus no "expected 181 version URI" is available. Simarily, the server may also return 183 >>Response 185 HTTP/1.1 200 OK 186 Cache-Control: no-cache 187 Content-Type: text/xml; charset="utf-8" 188 Content-Length: xxxx 190 191 192 ...other content... 193 194 where a response body is available, but it doesn't contain the 195 cu:expected-version-URI element. 197 4 Changes for CHECKIN method (when applied to a version-controlled 198 resource) 200 A client may submit the "expected version URI" (obtained during 201 CHECKOUT) upon a CHECKIN by placing it into a top-level cu:expected- 202 version-URI element in the request body. A server may 204 o simply ignore the presence of this information or 206 o use the information and try to checkin the resource using the 207 "expected version URI" as location for the version resource. A 208 failure to create a version resource at the "expected version URI" 209 MUST cause the operation to fail with a status code of 403 210 (forbidden) and a response body containing the top-level element 211 cu:cannot-assign-expected-version-URI. In addition, a server MAY 212 return a new "expected version URI" in it's response body. 214 4.1 Example for successful CHECKIN with computed version URI 216 >>Request 218 CHECKIN /foo.html HTTP/1.1 219 Host: www.webdav.org 220 Content-Type: text/xml; charset="utf-8" 221 Content-Length: xxxx 223 224 226 http://repo.webdav.org/his/23/ver/32 228 230 >>Response 232 HTTP/1.1 201 Created 233 Location: http://repo.webdav.org/his/23/ver/32 234 Cache-Control: no-cache 236 Note that the client can not rely on the server signaling an error if 237 the expected version URI could not be applied. It will have to 238 compare the URI returned in the HTTP "Location" header with the 239 requested version URI, and in the case of mismatch it MAY have to 240 report the situation to the user. 242 4.2 Example for failed CHECKIN with computed version URI 244 >>Request 246 CHECKIN /foo.html HTTP/1.1 247 Host: www.webdav.org 248 Content-Type: text/xml; charset="utf-8" 249 Content-Length: xxxx 251 252 254 http://repo.webdav.org/his/23/ver/32 256 258 >>Response 260 HTTP/1.1 403 Forbidden 261 Cache-Control: no-cache 262 Content-Type: text/xml; charset="utf-8" 263 Content-Length: xxxx 265 266 268 269 http://repo.webdav.org/his/23/ver/33 271 273 5 Compatibility Considerations 275 This specification does introduce new protocol elements for the 276 request and response bodies for CHECKIN and CHECKOUT. 278 Clients not aware of this specification will never submit the new 279 protocol elements in a request and therefore never will see the new 280 response elements. 282 Servers not aware of this specification will ignore the additional 283 two request body elements which is legal behaviour according to this 284 protocol (indicating that the protocol extension is not available). 286 6 Internationalization Considerations 288 This proposal builds on [RFC3253], and inherits its 289 internationalizability. 291 7 IANA Considerations 293 This proposal does not introduce any new IANA considerations, since 294 it does not specify any new namespaces (in the general sense), but 295 merely uses existing ones. 297 8 Copyright 299 To be supplied by the RFC Editor. 301 9 Intellectual Property 303 To be supplied by the RFC Editor. 305 References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.R. and 311 Jensen, D., "HTTP Extensions for Distributed Authoring -- 312 WEBDAV", RFC 2518, February 1999. 314 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and 315 Whitehead, J., "Versioning Extensions to WebDAV", RFC 316 3253, March 2002. 318 Author's Address 320 Julian F. Reschke 321 greenbytes GmbH 322 Salzmannstrasse 152 323 Muenster, NW 48159 324 Germany 326 Phone: +49 251 2807760 327 Fax: +49 251 2807761 328 EMail: julian.reschke@greenbytes.de 329 URI: http://www.greenbytes.de/tech/webdav/ 331 A Change Log 333 A.1 Since 'draft-reschke-deltav-compute-checkin-uri-00' 335 Made the document element for responses upon failed CHECKIN DAV:error 336 rather than DAV:checkin-response. 337 Updated reference to [RFC3253]. 338 Moved extension elements out of DAV: namespace. 339 Changed examples to explicitly use utf-8 encoding for HTTP content 340 type and XML encoding. 341 Globally replaced the term "CHECKIN URI" by "version URI" 342 Added note about how to discover whether the server actually applied 343 the expected version URI. 344 Made sure artwork (figures) fits into 72 columns. 346 Full Copyright Statement 348 Copyright (C) The Internet Society (2002). All Rights Reserved. 350 This document and translations of it may be copied and furnished to 351 others, and derivative works that comment on or otherwise explain it 352 or assist in its implementation may be prepared, copied, published 353 and distributed, in whole or in part, without restriction of any 354 kind, provided that the above copyright notice and this paragraph are 355 included on all such copies and derivative works. However, this 356 document itself may not be modified in any way, such as by removing 357 the copyright notice or references to the Internet Society or other 358 Internet organizations, except as needed for the purpose of 359 developing Internet standards in which case the procedures for 360 copyrights defined in the Internet Standards process must be 361 followed, or as required to translate it into languages other than 362 English. 364 The limited permissions granted above are perpetual and will not be 365 revoked by the Internet Society or its successors or assigns. 367 This document and the information contained herein is provided on an 368 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 369 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 370 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 371 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 372 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Acknowledgement 376 Funding for the RFC editor function is currently provided by the 377 Internet Society.