[Gen-art] Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-06

["Spencer Dawkins" <[e-mail]>]

Version 06 addresses all of my comments on 05, and other changes from 05 
look fine. Ready for publication as a Proposed Standard.

Spencer


> Hi, Cyrus,
>
> I have been selected as the General Area Review Team (Gen-ART) reviewer 
> for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd or AD before posting 
> a
> new version of the draft.
>
> 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.
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art