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

From: Cyrus Daboo <[email-masked]>
Date: Mon, 12 Nov 2007 12:18:20 -0500

Hi John,

--On November 12, 2007 8:50:55 AM -0800 John Barone <[email-masked]> 
wrote:

> I'll qualify this by saying I haven't read the spec yet (and I promise,
> I will), but why just MKCOL; why not PUT as well (maybe BIND too??? ...
> any method where you create an object)?   Again, without having read the
> spec. yet, seems like this might be focusing in on too specific a use
> case.
>
> I can see this being very useful for setting up collections that are
> meant to be used as "application bundles", but why not try to propose a
> more generic spec. that allows for applying meta-data templates to any
> resource.
>
> ... of, course easy to say from the sidelines; I should also say that
> Xythos would be very interested in contributing to/reviewing such a
> spec.

The extended MKCOL spec is focussed solely on addressing the current issue 
of too many MKxxx methods.

It would be a little more complex to do this with PUT. The reason it is 
easy with MKCOL is that the existing MKCOL does not take a body, so the 
extension data can be put in the request body.

With PUT, there is already a body being sent - i.e. the actual data of the 
resource. So there is no place to put the extension data, except for the 
request header (which would not be ideal). One solution, of course, would 
be to use a special MIME body with PUT, e.g. a multipart/mixed where the 
first part is application/webdav+properties, and the second part is the 
actual resource body data. Not sure what implication that might have.

-- 
Cyrus Daboo

---

From: "John Barone" <[email-masked]>
Date: Mon, 12 Nov 2007 08:50:55 -0800

.... of, course easy to say from the sidelines; I should also say that
Xythos would be very interested in contributing to/reviewing such a
spec. 

-John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Cyrus Daboo
Sent: Monday, November 12, 2007 6:58 AM
To: WebDAV
Subject: New draft: draft-daboo-webdav-mkcol-00.txt

Hi folks,
I have posted the following draft:

    A New Internet-Draft is available from the on-line Internet-Drafts
    directories.

    	Title           : Extended MKCOL for WebDAV
    	Author(s)       : C. Daboo
    	Filename        : draft-daboo-webdav-mkcol-00.txt
    	Pages           : 16
    	Date            : 2007-11-12

    This specification extends the WebDAV MKCOL method to allow
    collections and resources of arbitrary resourcetype to be created
and
    to allow properties to be set at the same time.

This draft arose from a discussion of the CardDAV spec where it was
noted we were starting to have too many MKxxx methods, and it would be
better to define a webdav generic extended MKCOL instead.

Please review and comment, thanks.

--
Cyrus Daboo

---

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

> spec. yet, seems like this might be focusing in on too specific a use

I'd say the reason is that we saw lots of specs creating new collection 
types with new methods, while MKCOL + additional information would be 
sufficient.

RFC2518 and RFC4918 left the body undefined, so here's an extension 
point we can use.

PUT doesn't have that extension point.

BIND doesn't create new resources but only new bindings to existing 
resources, so it doesn't seem to be relevant here.

> more generic spec. that allows for applying meta-data templates to any

That would be interesting as well, but would be IMHO a much harder 
problem to solve. So I think it makes a lot of sense to concentrate on 
that case.

> Xythos would be very interested in contributing to/reviewing such a

BR, Julian

---

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

Cyrus Daboo wrote:
> ...
> With PUT, there is already a body being sent - i.e. the actual data of 
> the resource. So there is no place to put the extension data, except for 
> the request header (which would not be ideal). One solution, of course, 
> would be to use a special MIME body with PUT, e.g. a multipart/mixed 
> where the first part is application/webdav+properties, and the second 
> part is the actual resource body data. Not sure what implication that 
> might have.
> ...

With PUT we would need a way to make sure that the recipient does 
understand the new MIME type we defined.

Instead of overloading PUT, using a body+metadata MIME type with PATCH 
might work better.

Best regards, Julian