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

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 UTC