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

Jamie Lokier wrote:
>>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.

ADDMEMBER is defined to do just that. If it would be accepted and become 
a standards-track RFC, yes, clients could rely on it just like they can 
rely on other HTTP methods today.

> 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?

Yes. For instance it could be used for Atom-Pub, and another use case 
was just suggested a few days ago internally at SAP (where a specific 
backend system has a concept of containment, but doesn't allow 
user-selected URIs).

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

I appreciate all the feedback I'm getting, and I'm very interested in 
ways that would avoid adding a new method while keeping the intended 
benefits.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 22 February 2005 21:42:14 UTC