W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 15 Feb 2005 20:01:55 +0100
Message-ID: <42124723.3090103@gmx.de>
To: Jamie Lokier <jamie@shareable.org>
CC: Cyrus Daboo <daboo@isamet.com>, HTTP Working Group <ietf-http-wg@w3.org>

Jamie Lokier wrote:
> These clients creating entities under different URIs -- what URI do
> they use in the request?
> They must use a URI which identifies what the server should do with
> the request, rather than identifying the URI of the new entity.
> (For example, a real implementation might use the URI identifying a
> particular mail folder or calendar in the request, and the request is
> to create a new message "inside" the identified folder or calendar,
> with a server-selected URI).
> When the request URI identifies an object which has internal logic and
> processes the request body -- isn't this quite well suited to POST?
> And, to get the URI of the created entity -- isn't this quite well
> suited to a 303 response from POST?
> (For example, POST to a mail folder or calender URI could reasonably
> create a new message "inside" the identified folder or calendar, if
> the request entity has an appropriate MIME type).

All of this is correct. However, how is a generic client going to know 
that sending a POST request to that container will indeed have the 
desired semantics of "storing the entity at a server-defined URI and 
returning the URI"?

If a protocol would use POST for this, it needs an out-of-band 
communication to ensure that the server indeed will process the POST as 
desired (for instance, the Atom publishing protocol does this through 
advertising serviceURLs). The proposed new method has fixed semantics 
and thus doesn't require out-of-band information.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 15 February 2005 19:02:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC