[VCARDDAV] comments on draft-ietf-vcarddav-webdav-mkcol-00

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@ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav