W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Feb 2005 14:54:38 +0100
Message-ID: <4214A21E.5070804@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>

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 

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 

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
Received on Thursday, 17 February 2005 13:55:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:31 UTC