[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

[Cyrus Daboo]

Hi Julian,

--On February 15, 2005 1:00:02 PM +0100 Julian Reschke 
<julian.reschke at gmx.de> wrote:

> recently different communities (caldav/groupdav, atompup (protocol
> part)) have been discussing how to use HTTP to author new resources when
> the URL namespace is completely server-controlled, thus PUT just doesn't
> fit well.
>
> A simple approach would be to define a new HTTP method which is *almost*
> like PUT, except that the server chooses the URL to create (and returns
> it in the Location header).
>
> I've submitted a first draft as "draft-reschke-http-addmember-00". Note
> that it also contains an appendix covering possible alternative
> approaches.
>
> Feedback appreciated,
>

Do we anticipate that MKCOL will also have the same problem as PUT? i.e. do 
we have to have an 'ADDCOLLECTION' method to take care of that case?

How is a client supposed to know to use ADDMEMBER as opposed to PUT? Does 
it have to check OPTIONS each time before it creates a resource in a new 
part of the URI hierarchy?

Is there any reason why we can't simply define a new status code for a PUT 
(or MKCOL) that results in the resource being renamed by the server? e.g.:

PUT /calendar/evt1.ics HTTP/1.1
Host: localhost
...

HTTP/1.1 2xx Created and Moved
Location: /calendar/xyz123.ics

Yes, this would probably break existing http clients doing a PUT, but those 
clients are going to have problems anyway since the server will rename the 
resource from under them anyway. What it does do is provide a clear 
indication for clients that can understand this behaviour. What is more 
this response code can be used on any method that creates resources without 
the need to have separate new methods for this. e.g. there are now a whole 
host of MKxxxx methods that may need the same treatment as PUT. The same 
probably applies to MOVE and COPY too.

-- 
Cyrus Daboo