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

[Julian Reschke <[e-mail]>]

Scott Lawrence wrote:
> On Mon, 2005-02-21 at 21:28 +0000, Jamie Lokier wrote:
> 
>>Scott Lawrence wrote:
>>
>>>>In which case I couldn't use the content-type of my actual request body 
>>>>for the Content-Type request header, right?
>>>
>>>I fear that I may have lost the thread of your comment... you cannot use
>>>Content-Type to send anything _but_ the content type of your request
>>>body.  
>>
>>Roy said that POST can take into account the request content type to
>>decide the action that is taken.
>>
>>I believe Julian wants to "create resource" with an arbitrary content
>>type - _without_ the content type having any effect on the action that
>>is taken to create the resource.
> 
> 
> But setting the content type of the resulting resource _is_ having an
> effect !?!
> 
> The point that I think Roy and I have both failed to communicate is
> this: POST does not in itself define what happens - the thing to which
> the request is POSTed (identified by the full URL) makes that decision. 

Well :-) I certainly am aware of that fact. That's the *reason* of 
proposing an alternate method that has strict semantics instead.

> That thing is free to use the URL, the content body, the time of day,
> the phase of the moon, or whatever it wants to when deciding what to do
> with the resource _and_you_get_to_choose_ because you are creating that
> thing.  If you want to define how you use POST in such a way that you
> say that the Content-Type of the body should be preserved in the new
> resource you are adding to the server, that's fine.  If you want to post
> an entity body in the request that encapsulates metadata about the
> resource with the resource itself (as is done in rfc1867 form file
> upload), that's fine too.  You already have what you need in POST -
> defining a new method does not add any new capability - it just adds
> ambiguity for the servers that don't know what it is (all intermediate
> systems already know that POST is not idempotent and the response to it
> can only be cached if the response so indicates - that's all you need).

I am fully aware that the desired semantics *can* be achieved with a 
well-defined message used with POST. The issue is that if multiple 
protocols (such as Caldav or Atompub) want to use the same semantics, it 
would be nice if they could use the same format, so that general purpose 
servers can take advantage of that. Whether that is some specific kind 
of POST, ADDMEMBER or PUT+Redirect (already dissed by Roy :-) is a 
separate issue here.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]