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

"Roy T. Fielding" <fielding@gbiv.com> Wed, 23 February 2005 08:30 UTC

X-Envelope-From: fielding@gbiv.com
X-Envelope-To: <ietf-caldav@osafoundation.org>
Received: from fed1rmmtao03.cox.net (fed1rmmtao03.cox.net [68.230.241.36]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1N8URaZ006354 for <ietf-caldav@osafoundation.org>; Wed, 23 Feb 2005 00:30:27 -0800
Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050223083022.GFSW1282.fed1rmmtao03.cox.net@[192.168.0.100]>; Wed, 23 Feb 2005 03:30:22 -0500
In-Reply-To: <20050223042608.GF4504@markbaker.ca>
References: <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> <c126af63ffe0c6f778badbaf438ca38c@gbiv.com> <20050223042608.GF4504@markbaker.ca>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <9ee689aeebb609c273b25296ff535c51@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
Date: Wed, 23 Feb 2005 00:24:07 -0800
To: Mark Baker <distobj@acm.org>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: WebDAV WG <w3c-dist-auth@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2005 08:30:28 -0000

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

....Roy