IETF Logo Mail Archive

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

"Roy T. Fielding" <fielding@gbiv.com> Tue, 22 February 2005 19:52 UTC

X-Envelope-From: fielding@gbiv.com
X-Envelope-To: <ietf-caldav@osafoundation.org>
Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MJqxaa008231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-caldav@osafoundation.org>; Tue, 22 Feb 2005 11:52:59 -0800
Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3g5a-0008KE-9P; Tue, 22 Feb 2005 11:52:58 -0800
In-Reply-To: <20050222133758.GD4504@markbaker.ca>
References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <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>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <c126af63ffe0c6f778badbaf438ca38c@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
Date: Tue, 22 Feb 2005 11:52:55 -0800
To: Mark Baker <distobj@acm.org>
X-Mailer: Apple Mail (2.619.2)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com
X-AntiAbuse: Original Domain - osafoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - gbiv.com
X-Source:
X-Source-Args:
X-Source-Dir:
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: Tue, 22 Feb 2005 19:53:00 -0000

On Feb 22, 2005, at 5:37 AM, Mark Baker wrote:
> Ah, so you're saying that ADDMEMBER isn't uniform?

Actually, no, I was saying that ADDMEMBER as currently defined
is identical to POST.  Julian said that it wasn't identical because
his client would be able to expect one semantic, namely that a
201 result would cause the webdav collection to contain a new
member with the given media type.  That implies an additional
requirement that the target be a webdav collection, which isn't
uniform at all.

> Can you give an example of a resource
> for which ADDMEMBER wouldn't make sense?

No, which is why it is POST by any other name.

....Roy

v2.23.0 | Report a Bug | By Email