W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Mark Baker <distobj@acm.org>
Date: Fri, 25 Feb 2005 00:35:09 -0500
To: HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV WG <w3c-dist-auth@w3.org>
Message-ID: <20050225053508.GA16308@markbaker.ca>

On Wed, Feb 23, 2005 at 12:24:07AM -0800, Roy T. Fielding wrote:
> On Feb 22, 2005, at 8:26 PM, Mark Baker wrote:
> >I still don't see how POST vs. ADDMEMBER is any different than POST
> >vs. PUT.  You previously said that PUT has "set the state of this
> >resource" semantics which is clearly different than POST.  IMO,
> >ADDMEMBER's semantics are very similar to PUT.  What (constraint?) am
> >I missing that suggests PUT is fine while ADDMEMBER isn't?
> You are missing that the target of PUT is the new resource,
> whereas the target of POST and ADDMEMBER are both the collection
> resource.  As such, ADDMEMBER's semantics has very little in
> common with PUT (almost nothing, in fact, since any unsafe
> extension method can return 201 and communicate just as much,
> whereas PUT is unique in what it communicates by the 200/201).

In case anybody's still following this thread 8-) ... I now find myself
in agreement with Roy, that POST is appropriate and that ADDMEMBER ==

I was looking at the interaction from the POV of a tweak on PUT
semantics, rather than as the submission of a document to a
state-preserving container (which I should have recognized it as
immediately, given my previous attempts at describing such a

I'm still not convinced that a POST extension (which declared the
expected type of the target resource) wouldn't improve the
self-descriptiveness of the message, but practically, that's pretty
much irrelevant for the purposes of this discussion.

 [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Friday, 25 February 2005 06:04:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC