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

Cyrus Daboo wrote:
>>> How is a client supposed to know to use ADDMEMBER as opposed to PUT?
>>> Does it have to check OPTIONS each time before it creates a resource in
>>> a new part of the URI hierarchy?
>>
>>
>> If it does have a name it can try the PUT which will fail; we could
>> define a simple way to find out that it's supposed to use ADDMEMBER
>> instead (such as a specific precondition name for DAV:error).
> 
> 
> But the PUT does not fail. It succeeds, however the server immediately 
> 'moves' the resource to a new location and the client does not know 
> about that. Alternatively the server would return a new '4xx Try 
> ADDMEMBER' response code - but I would argue my proposal for a '2xx 
> Created and Moved' is a better solution as it only needs one roundtrip.

The whole point of the proposal is to offer an alternative to what 
CalDav proposes, because (IMHO) that violates PUT semantics.

>> If it doesn't have a name it can try ADDMEMBER right away (which will
>> fail if the server can't do it).
> 
> 
> There are actually two problems here:
> 
> 1) Servers that cannot accept arbitrary client-generated URIs on new 
> resources and need to 'rename' those to something that is internally 
> consistent with its own policies.
> 
> 2) Clients that 'dont care' about the name of the resource being created 
> - they just want it to be unique and leave it up to the server to 
> generate the name.
> 
> I thought we were only trying to solve (1), but your ADDMEMBER proposal 
> also solves (2). However, (2) is also relevant for MKxxx, MOVE and COPY 
> and we don't have those solved.

It doesn't attempt to solve those for anything other than plain 
resources, and not for namespace operations. That's why it's so simple.

>>> Is there any reason why we can't simply define a new status code for a
>>> PUT (or MKCOL) that results in the resource being renamed by the server?
>>> e.g.:
>>>
>>> PUT /calendar/evt1.ics HTTP/1.1
>>> Host: localhost
>>> ...
>>>
>>> HTTP/1.1 2xx Created and Moved
>>> Location: /calendar/xyz123.ics
>>
>>
>> As far as I can tell, a server doing that wouldn't implement the
>> specified PUT semantics anymore.
> 
> 
> One could argue that the types of server we are talking about don't 
> implement PUT semantics anyway, by virtue of the fact that they move the 
> resource as soon as it is created without telling the client. So '2xx 
> Created and Moved' is no worse than the current state for existing 
> clients - but it is better for clients that are 'aware' of this behaviour.

Yes, but protocols should not mandate a behaviour that directly 
contradicts it's definition in the base protocol -- *even* if it applies 
only to special clients.

 > ...

Best regards, Julian


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

Received on Tuesday, 15 February 2005 16:52:05 UTC