Hi,first of all: I think it's a very good idea that the scope has been reduced to creating special *collections*. The general case of bundling of content and properties would be certainly be interesting as well, but that wouldn't be MKCOL anymore, nor would it belong into this working group (I think).
That being said...:1) <http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-00#section-1>
The introduction still talks about creating plain resources, and the DeltaV related cases. This should be removed. This also applies to Section 4.
2) The intro probably needs to state why the spec can use the DAV: namespace, and how the DTD fragments should be interpreted (see for instance <http://tools.ietf.org/html/draft-reschke-webdav-search-17#section-1>).
3) It probably would be good to state the MIME type for the request body (text/xml or application/xml), and also that xml-typed request bodies with a root element != DAV:mkcol are reserved for future usage (keep the extension point).
3) <http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-00#section-3.1>:
A server supporting the features described in this document, MUST include "extended-mkcol" as a field in the DAV response header from an OPTIONS request on any resource that supports use of the extended MKCOL method.
s/resource/URI/(that is probably less confusing because at the time the OPTIONS request is made, the URI is still unmapped)
4) <http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-00#section-5.1>:
<!ELEMENT mkcol (set+, ANY)>
I don't think that you can have that in a DTD. ANY allows anything anway. Get rid of "ANY", and refer to the WebDAV extensibility model instead. Same for Section 5.2.
BR, Julian _______________________________________________ VCARDDAV mailing list VCARDDAV at ietf.org https://www.ietf.org/mailman/listinfo/vcarddav