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

Cyrus Daboo wrote:
> 
> 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?

I'm not sure we really need to replace it anyway.

Looking back at the discussion that brought us here...: the main problem 
I saw was the arrival of new methods for creating new collection 
containers; basically standard WebDAV collections with new constraints 
for very specific business use cases.

I think that's worse than the special verbs in RFC3253, because 
versioning is orthogonal to all these use cases -- but maybe it's just 
me drawing the line somewhere else.


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

Either that or it should be implicit.

Let's not allow MKCOL to create something that isn't a collection.

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

We should, as it doesn't seem to be obvious.

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

No, please don't make it more generic. That will bring us back directly 
to MKRESOURCE, which in the end the WG did not want because of its 
complexity.

> ...

Best regards, Julian

Received on Monday, 19 November 2007 13:26:50 UTC