[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
julian.reschke at gmx.de
Tue Feb 15 08:51:29 PST 2005
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?
>>> 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
More information about the Ietf-caldav