idnits 2.17.1
draft-reschke-deltav-compute-checkin-uri-05.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:
----------------------------------------------------------------------------
== 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 ([2], [RFC3253], [1]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
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 (August 20, 2003) is 7553 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 329, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Reschke
3 Internet-Draft greenbytes
4 Expires: February 18, 2004 August 20, 2003
6 Computing the CHECKIN URI in WebDAV versioning
7 draft-reschke-deltav-compute-checkin-uri-05
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.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at http://
24 www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on February 18, 2004.
31 Copyright Notice
33 Copyright (C) The Internet Society (2003). All Rights Reserved.
35 Abstract
37 In many cases, a versioning-aware client might want to display/
38 include the URI of the version it's editing while it's being edited.
39 For instance, an editor might include this as meta information, or
40 the author of a document might want to know the URI of the version
41 before it's checked in. A well-known example is the W3C way of
42 referring to document versions in recommendations: it contains
43 references to "the current version", to "this version" and to the
44 "previous version". Something like this is currently impossible with
45 WebDAV versioning [RFC3253], as the version URI is determined at the
46 time of CHECKIN.
48 Distribution of this document is unlimited. Please send comments to
49 the WebDAV versioning (delta-V) mailing list at
50 ietf-dav-versioning@w3.org [1], which may be joined by sending a
51 message with subject "subscribe" to
52 ietf-dav-versioning-request@w3.org [2]. Discussions of the delta-V
53 mailing list are archived at URL: http://lists.w3.org/Archives/
54 Public/ietf-dav-versioning/.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
60 3. Changes for CHECKOUT method . . . . . . . . . . . . . . . . . 5
61 3.1 Example for successful CHECKOUT with computed version URI . . 5
62 3.2 Example for successful CHECKOUT without computed version
63 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
64 4. Changes for CHECKIN method (when applied to a
65 version-controlled resource) . . . . . . . . . . . . . . . . . 8
66 4.1 Example for successful CHECKIN with computed version URI . . . 8
67 4.2 Example for failed CHECKIN with computed version URI . . . . . 9
68 5. Compatibility Considerations . . . . . . . . . . . . . . . . . 10
69 6. Internationalization Considerations . . . . . . . . . . . . . 11
70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
71 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
73 A. Change Log (to be removed by RFC Editor before publication) . 14
74 A.1 Since 'draft-reschke-deltav-compute-checkin-uri-00' . . . . . 14
75 A.2 Since 'draft-reschke-deltav-compute-checkin-uri-01' . . . . . 14
76 A.3 Since 'draft-reschke-deltav-compute-checkin-uri-02' . . . . . 14
77 A.4 Since 'draft-reschke-deltav-compute-checkin-uri-03' . . . . . 14
78 A.5 Since 'draft-reschke-deltav-compute-checkin-uri-04' . . . . . 14
79 B. Resolved issues (to be removed by RFC Editor before
80 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 15
81 B.1 required-checkin-behaviour . . . . . . . . . . . . . . . . . . 15
82 Intellectual Property and Copyright Statements . . . . . . . . 16
84 1. Introduction
86 In many cases, a versioning-aware client might want to display/
87 include the URI of the version it's editing while it's being edited.
88 For instance, an editor might include this as meta information, or
89 the author of a document might want to know the URI of the version
90 before it's checked in. A well-known example is the W3C way of
91 referring to document versions in recommendations: it contains
92 references to "the current version", to "this version" and to the
93 "previous version". Something like this is currently impossible with
94 WebDAV versioning [RFC3253], as the version URI is determined at the
95 time of CHECKIN.
97 This specification builds on the infrastructure provided by the
98 WebDAV Versioning Protocol, adding support for servers willing to
99 compute an "expected version URI" upon CHECKOUT, and using this URI
100 at time of CHECKIN.
102 This document defines an extension element that could ultimately
103 become part of the WebDAV versioning protocol. Being just an
104 individual submission, it currently defines it in the proprietary
105 namespace
106 http://sapportals.com/xmlns/cm/webdav
108 instead of the "DAV:" namespace. It uses a prefix of "cu:" for
109 referring to elements in this namespace. However, WebDAV server and
110 clients are free to use any prefix, provided that there is a
111 namespace declaration that binds the prefix to the URI of the same
112 namespace.
114 2. Notational Conventions
116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
118 document are to be interpreted as described in [RFC2119].
120 3. Changes for CHECKOUT method
122 A client may ask for an "expected version URI" upon CHECKOUT (and the
123 CHECKIN variant with DAV:keep-checked-out request element). This is
124 done by placing cu:compute-expected-version-URI as top-level element
125 into the request body.
127 Additional Marshalling:
129 Presence of the cu:compute-expected-version-URI as top-level
130 element in the request body indicates that the server SHOULD
131 compute the "expected version URI". The server is free to either
132 ignore the request, or to return it's best guess about what the
133 URI for a version resource created upon CHECKIN would be.
135
137 The client can detect the "expected version URI" by parsing the
138 response body for a top-level element called
139 cu:expected-version-URI. Absence of this element (or absence of a
140 response body) indicates that the server is not able to compute
141 the URI.
143
145 3.1 Example for successful CHECKOUT with computed version URI
147 >>Request
149 CHECKOUT /foo.html HTTP/1.1
150 Host: www.example.org
151 Content-Type: text/xml; charset="utf-8"
152 Content-Length: xxxx
154
155
157
158
160 >>Response
162 HTTP/1.1 200 OK
163 Cache-Control: no-cache
164 Content-Type: text/xml; charset="utf-8"
165 Content-Length: xxxx
167
168
170
171 http://repo.example.org/his/23/ver/32
172
173
175 In this example, the server was able to compute the "expected version
176 URI" and returned it in the cu:expected-version-URI element.
178 3.2 Example for successful CHECKOUT without computed version URI
180 >>Request
182 CHECKOUT /foo.html HTTP/1.1
183 Host: www.example.org
184 Content-Type: text/xml; charset="utf-8"
185 Content-Length: xxxx
187
188
190
191
193 >>Response
195 HTTP/1.1 200 OK
196 Cache-Control: no-cache
198 In this case, no response body was returned, and thus no "expected
199 version URI" is available. Simarily, the server may also return
201 >>Response
203 HTTP/1.1 200 OK
204 Cache-Control: no-cache
205 Content-Type: text/xml; charset="utf-8"
206 Content-Length: xxxx
208
209
210 ...other content...
212
214 where a response body is available, but it doesn't contain the
215 cu:expected-version-URI element.
217 4. Changes for CHECKIN method (when applied to a version-controlled
218 resource)
220 A client may submit the "expected version URI" (obtained during
221 CHECKOUT) upon a CHECKIN by placing it into a top-level
222 cu:expected-version-URI element in the request body.
224 Additional Marshalling:
226 A top-level element cu:expected-version-URI, when present,
227 indicates the client's expectation about the URI of the version
228 that will be created by the CHECKIN operation.
230 Upon failure, the server MAY return a new "expected version URI"
231 in the DAV:error response body using the element
232 cu:expected-version-URI.
234 Additional Preconditions:
236 (cu:can-assign-expected-version-URI): if the server does support
237 the cu:compute-expected-version-URI extension upon CHECKOUT, it
238 MUST create the new version at the URI specified in the
239 cu:expected-version-URI or otherwise fail the request.
241 4.1 Example for successful CHECKIN with computed version URI
243 >>Request
245 CHECKIN /foo.html HTTP/1.1
246 Host: www.example.org
247 Content-Type: text/xml; charset="utf-8"
248 Content-Length: xxxx
250
251
253
254 http://repo.example.org/his/23/ver/32
255
256
258 >>Response
260 HTTP/1.1 201 Created
261 Location: http://repo.example.org/his/23/ver/32
262 Cache-Control: no-cache
264 4.2 Example for failed CHECKIN with computed version URI
266 >>Request
268 CHECKIN /foo.html HTTP/1.1
269 Host: www.example.org
270 Content-Type: text/xml; charset="utf-8"
271 Content-Length: xxxx
273
274
276
277 http://repo.example.org/his/23/ver/32
278
279
281 >>Response
283 HTTP/1.1 403 Forbidden
284 Cache-Control: no-cache
285 Content-Type: text/xml; charset="utf-8"
286 Content-Length: xxxx
288
289
291
292
293 http://repo.example.org/his/23/ver/33
294
295
297 Note that 403 (Forbidden) is returned because subsequent request with
298 the same expected version URI will always fail.
300 5. Compatibility Considerations
302 This specification does introduce new protocol elements for the
303 request and response bodies for CHECKIN and CHECKOUT.
305 Clients not aware of this specification will never submit the new
306 protocol elements in a request and therefore never will see the new
307 response elements.
309 Servers not aware of this specification will ignore the additional
310 two request body elements which is legal behaviour according to this
311 protocol (indicating that the protocol extension is not available).
313 6. Internationalization Considerations
315 This proposal builds on [RFC3253], and inherits its
316 internationalizability.
318 7. IANA Considerations
320 This proposal does not introduce any new IANA considerations, since
321 it does not specify any new namespaces (in the general sense), but
322 merely uses existing ones.
324 References
326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
327 Requirement Levels", BCP 14, RFC 2119, March 1997.
329 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
330 Jensen, "HTTP Extensions for Distributed Authoring --
331 WEBDAV", RFC 2518, February 1999.
333 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
334 Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
335 March 2002.
337 [1]
339 [2]
341 Author's Address
343 Julian F. Reschke
344 greenbytes GmbH
345 Salzmannstrasse 152
346 Muenster, NW 48159
347 Germany
349 Phone: +49 251 2807760
350 Fax: +49 251 2807761
351 EMail: julian.reschke@greenbytes.de
352 URI: http://greenbytes.de/tech/webdav/
354 Appendix A. Change Log (to be removed by RFC Editor before publication)
356 A.1 Since 'draft-reschke-deltav-compute-checkin-uri-00'
358 Made the document element for responses upon failed CHECKIN DAV:error
359 rather than DAV:checkin-response.
360 Updated reference to [RFC3253].
361 Moved extension elements out of DAV: namespace.
362 Changed examples to explicitly use utf-8 encoding for HTTP content
363 type and XML encoding.
364 Globally replaced the term "CHECKIN URI" by "version URI"
365 Added note about how to discover whether the server actually applied
366 the expected version URI.
367 Made sure artwork (figures) fits into 72 columns.
369 A.2 Since 'draft-reschke-deltav-compute-checkin-uri-01'
371 Updated abstract not to refer to DeltaV WG anymore. Use "WebDAV
372 versioning" instead of "deltaV".
373 Changed descriptions to use RFC3253's Marshalling/Precondition
374 format. Changed name of cu:cannot-assign-expected-version-URI to
375 cu:can-assign-expected-version-URI as this is a precondition.
377 A.3 Since 'draft-reschke-deltav-compute-checkin-uri-02'
379 Update marshalling to use DAV:href as container for URIs.
380 Clarify that the extension applies to CHECKOUT on version resources
381 and to CHECKIN/DAV:keep-checked-out as well.
383 A.4 Since 'draft-reschke-deltav-compute-checkin-uri-03'
385 Replaced domain names in examples according to RFC2606: "webdav.org"
386 by "example.org".
388 A.5 Since 'draft-reschke-deltav-compute-checkin-uri-04'
390 Remove superfluous IP and copyright sections. Swap "Introduction" and
391 "Notation" sections. Require server to support both extensions to
392 make behaviour more predictable.
394 Appendix B. Resolved issues (to be removed by RFC Editor before
395 publication)
397 Issues that were either rejected or resolved in this version of this
398 document.
400 B.1 required-checkin-behaviour
402 Type: change
404 julian.reschke@greebytes.de (2003-08-20): The CHECKIN extension is of
405 little value if the client can not detect beforehand whether it will
406 be respected.
408 Resolution: Require support for CHECKIN extension if the server does
409 support the CHECKOUT extension.
411 Intellectual Property Statement
413 The IETF takes no position regarding the validity or scope of any
414 intellectual property or other rights that might be claimed to
415 pertain to the implementation or use of the technology described in
416 this document or the extent to which any license under such rights
417 might or might not be available; neither does it represent that it
418 has made any effort to identify any such rights. Information on the
419 IETF's procedures with respect to rights in standards-track and
420 standards-related documentation can be found in BCP-11. Copies of
421 claims of rights made available for publication and any assurances of
422 licenses to be made available, or the result of an attempt made to
423 obtain a general license or permission for the use of such
424 proprietary rights by implementors or users of this specification can
425 be obtained from the IETF Secretariat.
427 The IETF invites any interested party to bring to its attention any
428 copyrights, patents or patent applications, or other proprietary
429 rights which may cover technology that may be required to practice
430 this standard. Please address the information to the IETF Executive
431 Director.
433 Full Copyright Statement
435 Copyright (C) The Internet Society (2003). All Rights Reserved.
437 This document and translations of it may be copied and furnished to
438 others, and derivative works that comment on or otherwise explain it
439 or assist in its implementation may be prepared, copied, published
440 and distributed, in whole or in part, without restriction of any
441 kind, provided that the above copyright notice and this paragraph are
442 included on all such copies and derivative works. However, this
443 document itself may not be modified in any way, such as by removing
444 the copyright notice or references to the Internet Society or other
445 Internet organizations, except as needed for the purpose of
446 developing Internet standards in which case the procedures for
447 copyrights defined in the Internet Standards process must be
448 followed, or as required to translate it into languages other than
449 English.
451 The limited permissions granted above are perpetual and will not be
452 revoked by the Internet Society or its successors or assignees.
454 This document and the information contained herein is provided on an
455 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
456 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
457 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
458 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
459 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
461 Acknowledgment
463 Funding for the RFC Editor function is currently provided by the
464 Internet Society.