idnits 2.17.1
draft-ietf-vcarddav-webdav-mkcol-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 424.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448.
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 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 (May 14, 2008) is 5826 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)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Daboo
3 Internet-Draft Apple Inc.
4 Intended status: Standards Track May 14, 2008
5 Expires: November 15, 2008
7 Extended MKCOL for WebDAV
8 draft-ietf-vcarddav-webdav-mkcol-00
10 Status of This Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of 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 November 15, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2008).
39 Abstract
41 This specification extends the WebDAV MKCOL method to allow
42 collections of arbitrary resourcetype to be created and to allow
43 properties to be set at the same time.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
49 3. WebDAV extended MKCOL . . . . . . . . . . . . . . . . . . . . 3
50 3.1. Extended MKCOL Support . . . . . . . . . . . . . . . . . . 4
51 3.1.1. Example: Using OPTIONS for the Discovery of
52 Support for extended MKCOL . . . . . . . . . . . . . . 4
53 3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 4
54 3.3. Additional Precondition for extended MKCOL . . . . . . . . 4
55 3.4. Example: Successful extended MKCOL Request . . . . . . . . 5
56 4. Replacing existing MKxxx methods . . . . . . . . . . . . . . . 6
57 4.1. MKCALENDAR replacement . . . . . . . . . . . . . . . . . . 6
58 4.1.1. Example: Replacing MKCALENDAR with MKCOL . . . . . . . 6
59 5. XML Element Definitions . . . . . . . . . . . . . . . . . . . 8
60 5.1. mkcol XML Element . . . . . . . . . . . . . . . . . . . . 8
61 5.2. mkcol-response XML Element . . . . . . . . . . . . . . . . 9
62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
66 Appendix A. Change History (to be removed prior to
67 publication as an RFC) . . . . . . . . . . . . . . . 10
69 1. Introduction
71 WebDAV [RFC4918] defines an HTTP [RFC2616] method MKCOL. This method
72 is used to create WebDAV collections on the server. However, several
73 WebDAV-based specifications (e.g., DeltaV [RFC3253], CalDAV
74 [RFC4791]) define "special" collections or resources - ones which are
75 identified by additional values in the DAV:resourcetype property
76 assigned to the collection resource, or through other means. These
77 "special" collections are created by new methods (e.g., MKACTIVITY,
78 MKWORKSPACE, MKCALENDAR). The addition of a new MKxxx method for
79 each new "special" collection or resource adds to server complexity
80 and is detrimental to overall reliability due to the need to make
81 sure intermediaries are aware of these methods.
83 This specification proposes an extension to the WebDAV MKCOL method
84 that adds a request body allowing a client to specify WebDAV
85 properties to be set on the newly created collection or resource. In
86 particular, the DAV:resourcetype property can be used to create a
87 "special" collection, or other properties used to create a "special"
88 resource. This avoids the need to invent new MKxxx methods.
90 2. Conventions Used in This Document
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94 document are to be interpreted as described in [RFC2119].
96 When XML element types in the namespace "DAV:" are referenced in this
97 document outside of the context of an XML fragment, the string "DAV:"
98 will be prefixed to the element type names.
100 3. WebDAV extended MKCOL
102 The WebDAV MKCOL request is extended to allow the inclusion of a
103 request body. The request body is an XML document containing a
104 single DAV:mkcol XML element at the top-level. One or more DAV:set
105 XML elements MAY be included in the DAV:mkcol XML element to allow
106 setting properties on the collection as it is created. In
107 particular, to create a collection of a particular type, the DAV:
108 resourcetype XML element MUST be included in a DAV:set XML element
109 and MUST specify the correct resource type elements for the new
110 resource.
112 As per the PROPPATCH method, servers MUST process any DAV:set
113 instructions in document order (an exception to the normal rule that
114 ordering is irrelevant). Instructions MUST either all be executed or
115 none executed. Thus, if any error occurs during processing, all
116 executed instructions MUST be undone and a proper error result
117 returned. Failure to set a property value on the collection MUST
118 result in a failure of the overall MKCOL request.
120 If a server attempts to make any of the property changes in an
121 extended MKCOL request (i.e., the request is not rejected for high-
122 level errors before processing the body), the response MUST be an XML
123 document containing a single DAV:mkcol-response XML element, which
124 MUST contain DAV:propstat XML elements with the status of each
125 property.
127 In all other respects the behavior of the extended MKCOL request
128 follows that of the standard MKCOL request.
130 3.1. Extended MKCOL Support
132 A server supporting the features described in this document, MUST
133 include "extended-mkcol" as a field in the DAV response header from
134 an OPTIONS request on any resource that supports use of the extended
135 MKCOL method.
137 3.1.1. Example: Using OPTIONS for the Discovery of Support for extended
138 MKCOL
140 >> Request <<
142 OPTIONS /addressbooks/users/ HTTP/1.1
143 Host: addressbook.example.com
145 >> Response <<
147 HTTP/1.1 200 OK
148 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
149 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
150 DAV: 1, 2, 3, access-control, extended-mkcol
151 Date: Sat, 11 Nov 2006 09:32:12 GMT
152 Content-Length: 0
154 3.2. Status Codes
156 As per Section 9.3.1 of [RFC4918].
158 3.3. Additional Precondition for extended MKCOL
160 WebDAV [RFC4918] (Section 16) defines preconditions and
161 postconditions for request behavior. This specification adds the
162 following precondition for the extended MKCOL request.
164 Name: valid-resourcetype
166 Use with: Typically 403 Forbidden
168 Purpose: (precondition) -- The server does not support the specified
169 resourcetype value for any collections.
171 3.4. Example: Successful extended MKCOL Request
173 This example shows how the extended MKCOL request is used to create a
174 collection of a fictitious type "special-resource".
176 >> Request <<
178 MKCOL /home/special/ HTTP/1.1
179 Host: special.example.com
180 Content-Type: application/xml; charset="utf-8"
181 Content-Length: xxxx
183
184
186
187
188
189
190
191
192 Special Resource
193
194
195
196 >> Response <<
198 HTTP/1.1 201 Created
199 Cache-Control: no-cache
200 Date: Sat, 11 Nov 2006 09:32:12 GMT
201 Content-Type: application/xml; charset="utf-8"
202 Content-Length: xxxx
204
205
206
207
208
209
210
211 HTTP/1.1 200 OK
212
213
215 4. Replacing existing MKxxx methods
217 One of the goals of this extension is to eliminate the need for other
218 extensions to define their own variant of MKCOL to create the special
219 collections they need. This extension can be used to replace
220 existing MKxxx methods in other extensions as detailed below. If a
221 server supports this extension and the other extension listed, then
222 the server MUST support use of the extended MKCOL method to achieve
223 the same result as the MKxxx method of the other extension.
225 4.1. MKCALENDAR replacement
227 CalDAV [RFC4791] defines the MKCALENDAR method to create a calendar
228 collection as well as set properties during creation.
230 The extended MKCOL method can be used instead by specifying both DAV:
231 collection and CALDAV:calendar-collection XML elements in the DAV:
232 resourcetype property, set during the extended MKCOL request.
234 4.1.1. Example: Replacing MKCALENDAR with MKCOL
236 The first example below shows an MKCALENDAR request containing a
237 CALDAV:mkcalendar XML element in the request body, and returning a
238 CALDAV:mkcalendar-response XML element in the response body. The
239 second example shows the equivalent extended MKCOL request with the
240 same request and response XML elements.
242 >> MKCALENDAR Request <<
244 MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
245 Host: calendar.example.com
246 Content-Type: application/xml; charset="utf-8"
247 Content-Length: xxxx
249
250
252
253
254 Lisa's Events
255
256
257
259 >> MKCALENDAR Response <<
261 HTTP/1.1 201 Created
262 Cache-Control: no-cache
263 Date: Sat, 11 Nov 2006 09:32:12 GMT
264 Content-Type: application/xml; charset="utf-8"
265 Content-Length: xxxx
267
268
270
271
272
273
274 HTTP/1.1 200 OK
275
276
277 >> MKCOL Request <<
279 MKCOL /home/cyrus/calendars/events/ HTTP/1.1
280 Host: calendar.example.com
281 Content-Type: application/xml; charset="utf-8"
282 Content-Length: xxxx
284
285
287
288
289
290
291
292
293 Cyrus' Events
294
295
296
298 >> MKCOL Response <<
300 HTTP/1.1 201 Created
301 Cache-Control: no-cache
302 Date: Sat, 11 Nov 2006 09:32:12 GMT
303 Content-Type: application/xml; charset="utf-8"
304 Content-Length: xxxx
306
307
309
310
311
312
313
314 HTTP/1.1 200 OK
315
316
318 5. XML Element Definitions
320 5.1. mkcol XML Element
321 Name: mkcol
323 Namespace: DAV:
325 Purpose: Used in a request to specify properties to be set in an
326 extended MKCOL request, as well as any additional information
327 needed when creating the resource.
329 Description: This XML element is a container for the information
330 required to modify the properties on a collection resource as it
331 is created in an extended MKCOL request.
333 Definition:
335
337 5.2. mkcol-response XML Element
339 Name: mkcol-response
341 Namespace: DAV:
343 Purpose: Used in a response to indicate the status of properties
344 that were set or failed to be set during an extended MKCOL
345 request.
347 Description: This XML element is a container for the information
348 returned about a resource that has been created in an extended
349 MKCOL request.
351 Definition:
353
355 6. Security Considerations
357 This extension does not introduce any new security concerns beyond
358 those already described in HTTP and WebDAV.
360 7. IANA Considerations
362 This document does not require any actions on the part of IANA.
364 8. Acknowledgments
366 Several people suggested this approach, including Julian Reschke and
367 Bernard Desruisseaux.
369 9. Normative References
371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
372 Requirement Levels", BCP 14, RFC 2119, March 1997.
374 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
375 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
376 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
378 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
379 Whitehead, "Versioning Extensions to WebDAV
380 (Web Distributed Authoring and Versioning)", RFC 3253,
381 March 2002.
383 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
384 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
385 March 2007.
387 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
388 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
390 Appendix A. Change History (to be removed prior to publication as an
391 RFC)
393 Changes from draft-daboo-webdav-mkcol-00:
395 1. Removed MKACTIVITY and MKWORKSPACE replacement behavior.
397 2. Added valid-resourcetype precondition.
399 Author's Address
401 Cyrus Daboo
402 Apple Inc.
403 1 Infinite Loop
404 Cupertino, CA 95014
405 USA
407 EMail: cyrus@daboo.name
408 URI: http://www.apple.com/
410 Full Copyright Statement
412 Copyright (C) The IETF Trust (2008).
414 This document is subject to the rights, licenses and restrictions
415 contained in BCP 78, and except as set forth therein, the authors
416 retain all their rights.
418 This document and the information contained herein are provided on an
419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
426 Intellectual Property
428 The IETF takes no position regarding the validity or scope of any
429 Intellectual Property Rights or other rights that might be claimed to
430 pertain to the implementation or use of the technology described in
431 this document or the extent to which any license under such rights
432 might or might not be available; nor does it represent that it has
433 made any independent effort to identify any such rights. Information
434 on the procedures with respect to rights in RFC documents can be
435 found in BCP 78 and BCP 79.
437 Copies of IPR disclosures made to the IETF Secretariat and any
438 assurances of licenses to be made available, or the result of an
439 attempt made to obtain a general license or permission for the use of
440 such proprietary rights by implementers or users of this
441 specification can be obtained from the IETF on-line IPR repository at
442 http://www.ietf.org/ipr.
444 The IETF invites any interested party to bring to its attention any
445 copyrights, patents or patent applications, or other proprietary
446 rights that may cover technology that may be required to implement
447 this standard. Please address the information to the IETF at
448 ietf-ipr@ietf.org.
450 Acknowledgement
452 Funding for the RFC Editor function is provided by the IETF
453 Administrative Support Activity (IASA).