- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 19 Nov 2007 14:13:47 +0100
- To: Werner Baumann <werner.baumann@onlinehome.de>
- CC: w3c-dist-auth@w3.org
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
Received on Monday, 19 November 2007 13:14:08 UTC