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

Jamie Lokier wrote:
>>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?

Well, not yet. The whole point of this is that potentially 
Groupdav/Caldav/Atompub clients can go ahead and use ADDMEMBER instead 
of having to invent their own solution to the problem (which is a matter 
of fact at the time of this writing is an extended PUT for *dav and a 
atom-specific POST for atompub).

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

OK, "out-of-band" probably was a bad choice of words.

Using OPTIONS and the "Allow" response header is entirely covered by 
RFC2616. Thus, if a server says "I can apply ADDMEMBER to this 
resource", and ADDMEMBER is published as standards-track IETF document, 
clients can be reasonably sure that sending an ADDMEMBER request will 
have the desired effect.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 15 February 2005 20:04:41 UTC