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: Tue, 15 Feb 2005 17:51:29 +0100
Message-ID: <42122891.3010801@gmx.de>
To: Cyrus Daboo <daboo@isamet.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>, ietf-caldav@osafoundation.org

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC