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

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

From: Jamie Lokier <jamie@shareable.org>
Date: Tue, 15 Feb 2005 19:51:06 +0000
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Cyrus Daboo <daboo@isamet.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20050215195106.GA13696@mail.shareable.org>

Julian Reschke wrote:
> 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"?

Can you give an example of such a generic client being used?

I'm finding it hard to imagine a scenario where a generic client would
be asked to do this, where the caller of the generic client wouldn't
already know what to expect.

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

It does require out-of-band information if the proposal for using
OPTIONS is needed: OPTIONS is the out-of-band information.

Otherwise the client is back to making assumptions about the server's
behaviour.

-- Jamie
Received on Tuesday, 15 February 2005 19:51:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT