W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
Date: Tue, 22 Feb 2005 00:19:23 -0500
Message-ID: <421AC0DB.6000001@oracle.com>
To: WebDAV <w3c-dist-auth@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
CC: Cyrus Daboo <daboo@isamet.com>, Julian Reschke <julian.reschke@gmx.de>, "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>

Ideally we would have a solution that would work for all methods that
may request the creation of a new resource (e.g, LOCK, PUT, COPY, MOVE,

Could the solution be as simple as specifying an empty query component
(e.g., "?") in the Request-URI for those methods, and have the methods
return the Location header as part of their response?

For instance,

   PUT /calendar/bernard/?

would request the server to create a new resource in the collection
/calendar/bernard/ and let the server chose the name of the resource.

Is there already a defined use for the query component for the methods
mentionned above?


Cyrus Daboo wrote:

> Hi Julian,
> --On February 17, 2005 2:54:38 PM +0100 Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> 1) CalDav's approach is: use PUT to an arbitrary member URI of the
>> container; then let the server automagically move it somewhere else, and
>> report that in the Location response header
>> (<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html#r
>> fc.section.A.2>).
> I want to add that in the CalDAV case this URI naming restriction will 
> also apply to COPY and MOVE methods too, not just PUT. So we do need to 
> come up with a solution that at least works with those methods too. Of 
> course it is possible to emulate COPY and MOVE using PUT (client 
> downloads original data, creates it in new location) and DELETE (remove 
> old data in the case of MOVE) - but we should really have the proper 
> atomic operations for this.
Received on Tuesday, 22 February 2005 05:33:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC