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

[Julian Reschke]

Roy T. Fielding wrote:

> POST is always an attempt to store state.  It is the response that
> tells you whether the state has been stored.  No POST can be
> interpreted by intermediaries, just as no "ADDMEMBER" can either.
> The system gains nothing from adding a new method.  It might have
> gained something by not allowing HTML forms to use POST for safe
> actions, but that debate ended years ago.  Creating new unsafe
> actions that do the same as what POST has already been defined
> to do is absurd.

Well, ADDMEMBER does not do the same thing. It's specced to do *one* 
very specific thing, while POST basically allows the server to do 
anything it likes.

>> Had HTTP a means for extending a method to declare this additional
>> expectation (as described in the draft's A.3 using RFC 2774), I agree
>> that POST + extension would be appropriate.
> 
> 
> It doesn't because it never needed it.

OK, let's step back and look at the situation that caused me to make 
this proposal.

Two separate communities (CalDAV/GroupDav and Atompub) encountered the 
same issue: what's the best way to create a new resource on an HTTP 
server when I can't use PUT as the URI space may be entirely 
server-controlled?

1) CalDav's approach is: use PUT to an arbitrary member URI of the 
container; then let the server automagically move it somewhere else, and 
report that in the Location response header 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html#rfc.section.A.2>).

2) Atom's approach is to use service URIs to which the client can POST, 
and to discover these service URIs by parting entity (feed) bodies.


Somehow I have the (perhaps naive) wish that identical requirements 
should lead to common protocol constructs.

1) Seems to break PUT semantics;

2) Is specific to Atom and not applicable to other protocols.

 > ...
> The media type is not limited in HTTP and it is not equivalent
> to data format.  The media type tells the recipient how to process
> the message given the method semantics.  That is why sending the
> same data as "text/html" is functionally different from sending it
> as "text/plain" -- the two messages have different semantics.
> 
> That will hold for anything compliant with HTTP/1.1.

So what would be your recommendation to the authors of CalDav and the 
Atom Publishing Protocol? What's the best way to add a new member to a 
container (storing the entity just like PUT, but letting the server 
decide on the URI)?


Best regards, Julian

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