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

Julian Reschke wrote:
> "The PUT method requests that the enclosed entity be stored under the 
> supplied Request-URI. If the Request-URI refers to an already existing 
> resource, the enclosed entity SHOULD be considered as a modified version 
> of the one residing on the origin server. If the Request-URI does not 
> point to an existing resource, and that URI is capable of being defined 
> as a new resource by the requesting user agent, the origin server can 
> create the resource with that URI."
> 
> That is, a server that stores the entity under a different URI than the 
> one provided by the client isn't doing what the client asked for.
> 
> Therefore I propose that the client should explicitly state what it 
> wants. One approach is a new method, other approaches would be to extend 
> the PUT *request*.

These clients creating entities under different URIs -- what URI do
they use in the request?

They must use a URI which identifies what the server should do with
the request, rather than identifying the URI of the new entity.

(For example, a real implementation might use the URI identifying a
particular mail folder or calendar in the request, and the request is
to create a new message "inside" the identified folder or calendar,
with a server-selected URI).

When the request URI identifies an object which has internal logic and
processes the request body -- isn't this quite well suited to POST?

And, to get the URI of the created entity -- isn't this quite well
suited to a 303 response from POST?

(For example, POST to a mail folder or calender URI could reasonably
create a new message "inside" the identified folder or calendar, if
the request entity has an appropriate MIME type).

-- Jamie

Received on Tuesday, 15 February 2005 18:32:16 UTC