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

Hi Werner,

--On November 18, 2007 5:43:46 PM +0100 Werner Baumann 
<werner.baumann@onlinehome.de> 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.

Yup, that was one thing I was a little concerned about. The issue is that 
MKACTIVITY (one of the MKxxx's we wanted to replace) actually creates a 
non-collection resource. So I designed MKCOL to do the same.

Now there was some discussion about have another method of extension to PUT 
that would also allow properties to be set at the time of creation of a 
resource. So maybe that should be used (once defined) to replace MKACTIVITY?


> 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.

So are you also saying that MKCOL with XML body MUST specify at least 
DAV:collection on the DAV:resourcetype property?

> 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.

The extra elements are needed to encapsulate the existing extra elements 
defined by MKWORKSPACE and MKACTIVITY.

> 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, for backwards compatability with MKWORLSPACE and MKACTIVITY we do 
need it. But we could certainly add text to say there is no need to return 
the mkcol-response if the only thing being done was setting properties and 
that worked.

> 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.

Sure, use of an unsupported resourcetype must cause a failure. Is that 
something we want to call out as a special pre-condition on MKCOL (i.e. 
have a DAV:error element for it)?

> 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.

>From what I can tell RFC3253 did not define exactly what those elements are 
for - i.e. there could be more than properties in there. Obviously if some 
implementation was using them for properties we would need to make sure 
that MKCOL's top-level propupdate be used instead.

Now, if it turns out that no one has ever used those elements, how about 
deprecating them? If they were designed for setting just properties, then 
extended MKCOL can cover that just fine. If we were to do that, then we 
could get rid of mkcol and mkcol-response elements. That would certainly 
simplify things.

> Extensions:
> When considering the inclusion of an XML-body in MCOL, I also would
> prefer to make this more generic and include other methods, including PUT
> as well.

Um, well the PUT body is the actual resource data! In previous message I 
suggested we could use a multipart where one part was e.g., 
application/xml+webdav, and the other part was the actual resource data.

> Additionally, why only set properties. It would be nice, if a
> LOCK-request could be included too. This would not only save one
> round-trip (not such important), but avoid race conditions. But allowing
> a LOCK-request in the XML-body would require a new container-element for
> the request-body. It should be something generic, like a
> "request"-element.

Well that was what the mkcol element was designed to do. But being more 
generic by having an application/xml+webdav content with 'request' as the 
top-level element would be fine too.

> Werner
>
> P.S: "displayname"
> This example from the draft is how not to use it:
>           <D:resourcetype>
>             <D:collection/>
>             <E:special-resource/>
>           </D:resourcetype>
>           <D:displayname>Special Resource</D:displayname>
> Why repeat the value of another property. But displayname is useless
> anyway. Never heard of another "name", that must *not* be used for
> identifying.

Well that was just an example. The "value" is not repeated as 
"special-resource" is an element. I can certainly change the text in the 
displayname to something different.

Not sure why you think displayname is useless though...

-- 
Cyrus Daboo

Received on Monday, 19 November 2007 03:51:11 UTC