Document: draft-ietf-vcarddav-webdav-mkcol-05 Reviewer: Spencer Dawkins IETF LC End Date: 2009-08-17 Review Date: 2009-08-07 IESG Telechat date: (not known) Summary: This document is almost ready for publication as a Proposed Standard. I have some minor comments (identified as "Spencer (minor)" in the following text, but nothing that should slow document approval. In particular, I'm pretty sure I identified an error in the title for Section 3.5 below. Comments identified as "Spencer (clarity)" are provided for editors, but are not part of the Gen-ART review. Abstract This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. Spencer (clarity): I know that RFC 4918 didn't provide an expansion for MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL appears in the abstract for this document, it might be helpful to s/MKCOL/MKCOL ("Make Collection")/ here. MKCOL is defined at first use in the Introduction, so that's fine - this is only a suggestion about the abstract. 3. WebDAV extended MKCOL The WebDAV MKCOL request is extended to allow the inclusion of a request body. The request body is an XML document containing a single DAV:mkcol XML element as the root element. The Content-Type Spencer (minor): if I'm reading this paragraph correctly, I'd suggest "The request body is an XML document that MUST contain a single DAV:mkcol XML element as the root element" here - the last sentence in this paragraph makes me think the requirement is normative, but it doesn't look normative to 2119 scanners :-) request header MUST be set appropriately for an XML body (e.g., set to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL request that do not have DAV:mkcol as the root element are reserved for future usage. As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST process any DAV:set instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs Spencer (clarity): this sentence reads roughly to me, and it's 2119 language, so needs to be clear. I suggest "The set of instructions MUST be executed atomically; either all are executed or none are executed". during processing, all executed instructions MUST be undone and a proper error result returned. Failure to set a property value on the collection MUST result in a failure of the overall MKCOL request - i.e. the collection is not created. 3.5. Example: Successful Extended MKCOL Request Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's returning a 403/424 :D 4. Replacing Existing MKxxx Methods Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite about REPLACING existing MKxxx methods, but more like "Providing MKxxx functionality using extended MKCOL". Would that be clearer? The current text in 4.1 sent me looking to see whether "replacement" meant "deprecation" (it doesn't, if I'm reading clearly), for example. One of the goals of this extension is to eliminate the need for other extensions to define their own variant of MKCOL to create the special collections they need. This extension can be used to replace existing MKxxx methods in other extensions as detailed below. If a server supports this extension and the other extension listed, then the server MUST support use of the extended MKCOL method to achieve the same result as the MKxxx method of the other extension.