[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
distobj at acm.org
Fri Feb 18 06:42:55 PST 2005
On Wed, Feb 16, 2005 at 05:45:46PM -0800, Roy T. Fielding wrote:
> On Feb 16, 2005, at 4:53 AM, Mark Baker wrote:
> >On Tue, Feb 15, 2005 at 03:02:46PM -0800, Roy T. Fielding wrote:
> >>This feature of HTTP is already defined as
> >> POST + media-type ==> 201 + location
> >I was thinking the same thing Roy, but a new method would have the
> >advantage of improved visibility; an intermediary observing a POST/201
> >interaction wouldn't see anything in the POST request which licensed it
> >to interpret that request as an attempt to store state, whereas a new
> >method would provide exactly that license.
> POST is always an attempt to store state.
I meant "store" in the "file->save" sense of the word, where the
resulting state of the server includes *some* resource whose state is
represented by the representation included in the request. For PUT, the
Request-URI would identify that resource, while for ADDMEMBER, the
server would mint a new resource with that state.
> >>The media type is more than
> >>sufficient to distinguish this action from any other type of
> >>misdirected POST,
> >How so?
> Because the target URI knows what type of collection it is and
> how to process POST requests.
Right, but it seems to me that operation and media type should be
orthogonal. So assuming they aren't would, at best, be limiting the
ability of the operation to be used with different media types.
> >But even if there was such a limitation, that seems a bit
> >kludgy to me; could such an assumption be expected to hold for even the
> >foreseeable future? I wouldn't have thought so.
> The media type is not limited in HTTP and it is not equivalent
> to data format. The media type tells the recipient how to process
> the message given the method semantics. That is why sending the
> same data as "text/html" is functionally different from sending it
> as "text/plain" -- the two messages have different semantics.
Understood. I've championed that position before, in fact.
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
More information about the Ietf-caldav