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

From: Werner Baumann <[email-masked]>
Date: Sun, 18 Nov 2007 17:43:46 +0100

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.

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.

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.

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.

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.

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.

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

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.

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 18 Nov 2007 22:50:51 -0500

Hi Werner,

--On November 18, 2007 5:43:46 PM +0100 Werner Baumann 
<[email-masked]> wrote:

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

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

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

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

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

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

> the request-body. It should be something generic, like a

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.

> anyway. Never heard of another "name", that must *not* be used for

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Nov 2007 14:13:47 +0100

> But never use it to create non-collections. This kind of misnomer will 

+1.

> be called MKCOL, maybe MKRES.

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

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

> cases, multistatus and response should do the job.

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

> RFC 4918, the server would be allowed to just create a dead property.

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Nov 2007 14:19:47 +0100

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

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

> have a DAV:error element for it)?

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

> 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