Re: New draft: draft-daboo-webdav-mkcol-00.txt

Julian Reschke <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <[email protected]>
Werner Baumann wrote:
> 
> MKCOL for non-collections?
> MKCOL should not create anything but collections. These may be special 
> kinds of collections, and there may be a body included (as proposed). 
> But never use it to create non-collections. This kind of misnomer will 
> strike back some day.

+1.

> If there are special kinds of non-collection resources, that can not be 
> created using PUT (eventually with additional XML-body), they probably 
> need a new method. Maybe this could be some kind of generic method for 
> different kinds of non-collection resources. It might be better to have 
> one method to create collections and non-collections. But this must not 
> be called MKCOL, maybe MKRES.

This was once proposed as MKRESOURCE (early drafts of the redirect 
spec), but later rejected.

> Setting properties:
> As long as the XML-body is only needed to set properties (including a 
> special resource-type), I cannot see the need for additional 
> XML-elements (mkcol and mkcol-response). Everything needed to set 
> properties is already in RFC 4918.

I would argue in favor of keeping the top level argument, because it's 
consistent with all the later WebDAV specs.

> As the extended MKCOL-method is defined to be "all or nothing", there is 
> usually no need for a response-body, the status-line will suffice. It is 
> useless to list all properties, that are set. If the request succeeds, 
> they are all set. If there is a need for some response-body in special 
> cases, multistatus and response should do the job.

Again, I would propose to leave things as defined for consistency with 
other methods.

> Special collections:
> Special collections will be defined by an additional resourcetype 
> property. As this collection may be expected to behave different from 
> standard collections, it is essential that the server knows about this 
> special kind and supports it. It must be stated clearly, that the 
> request must fail, if the server does not know this resourcetype or does 
> not support it. I am not clear about this, but I believe according to 
> RFC 4918, the server would be allowed to just create a dead property.

DAV:resourcetype can not be a dead property. Ever.

> As the special collection is defined by its resourcetype, I can not see 
> any need for mkworkspace, mkactivity and similar XML-elements. As far as 
> I can see, they just contain properties.

I think the examples contain more.

That being said, I'd propose to leave out everything about RFC3253.

> ...

Best regards, Julian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.