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.