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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 18 Feb 2005 00:05:56 +0100
Message-ID: <42152354.1090407@gmx.de>
To: Jamie Lokier <jamie@shareable.org>
CC: algermissen@acm.org, "Roy T. Fielding" <fielding@gbiv.com>, 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>

Jamie Lokier wrote:
> which I took to mean you wanted to be sure of what would happen,
> perhaps with a view to a security policy or intermediary behaviour.
> My mistake.
> 
> So I'll humbly rephrase my question:
> 
> Even if you do specify ADDMEMBER more tightly (than POST), I still
> don't see how the difference would benefit you.  You say it is useful
> to have an idea what the server will do with a POST, in general.  In
> general means an arbitrary URI with unknown properties, because if
> it's a URI with known properties, you know exactly what POST will do.
> 
> How does specifying ADDMEMBER to have tighter semantics than PUT and
> POST benefit you when sending the request to an arbitrary URI with
> unknown properties?  Can you give an example?

The same way as COPY, LOCK, MOVE, VERSION-CONTROL, 
<insert-your-favorite-method-here>...

I don't think I understand your point. Any operation *can* be marshalled 
through POST, but that doesn't mean it's the best way to do it.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 17 February 2005 23:06:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT