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

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

From: Jamie Lokier <jamie@shareable.org>
Date: Tue, 22 Feb 2005 21:19:08 +0000
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDAV <w3c-dist-auth@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20050222211908.GH22555@mail.shareable.org>

Julian Reschke wrote:
> Jamie Lokier wrote:
> >...
> >If it's done, the behaviour of the server is unpredictable.  ADDMEMBER
> >doesn't fix that.
> >...
> You keep saying that :-) So are you saying that defining new methods 
> never ever is the right approach, because there are broken servers out 
> there?

No I'm not saying that.

One of the rationales given in this thread for ADDMEMBER is that the
tighter semantics mean that clients can depend on it literally adding
a new resource which is GETable, or failing with Method Not Supported.

I'm saying that particular rationale isn't logically sound.

It doesn't negate any other rationales you may have up your sleeve :)

> ADDMEMBER is a generic method. It doesn't have anything specific to do 
> with CalDAV except that it *could* be used with CalDAV.

Indeed, but are there realistic applications in mind that would use
ADDMEMBER without caring what kind of container resource it is, but do
care that it is a container and not a form processor?

If there are it makes more sense.  If there aren't, it's unneeded.

I think your exploration of the WebDAV text concerning why POST isn't
used on containers is a good one, btw.

-- Jamie
Received on Tuesday, 22 February 2005 21:19:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC