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

Roy T. Fielding wrote:
> ...
>> By defining a way to discover WebDAV collections 
>> (DAV:resourcetype/DAV:collection in PROPFIND response), a client can 
>> find out whether a resource is a WebDAV collection or isn't. Also, 
>> WebDAV defines COPY and MOVE as namespace operations that take 
>> containment into account.
> 
> 
> Completely irrelevant -- COPY and MOVE are HTTP operations on any
> collection, not just webdav collections, and will succeed or fail
> regardless of whether the client previously checked its pacifier.

Yes, but that doesn't mean it's irrelevant whether a resource is a 
collection or not. It just means that you don't *have* to check before 
you apply namespace operations.

>> I'm not sure why this is a problem; and in particular I'd like to know 
>> what a better solution would have been.
> 
> 
> There was no problem -- it was a solution to someone's angst.

So how *should* a WebDAV collection have been defined?

>>> absolutely moronic implementations that have to test each resource
>>> for the set of methods it implements before performing a set of
>>> actions that would have the same result as a generic POST.
>>
>>
>> Right, those are moronic implementations (because in general, a client 
>> can safely try the method and then handle HTTP's "method not allowed" 
>> status code gracefully).
>>
>> On the other hand, using distinct methods allows to use a 
>> discovery/failure signalling approach that uses plain HTTP (OPTIONS 
>> method, "Allow" response header, 405 status).
> 
> 
> Which is completely unnecessary in HTTP.

The 405 status and the Allow response header are unnecessary?

>>> [Which is to say that it will suck every bit as much as the other
>>> methods introduced by webdav and its prodigy that created arbitrary
>>> resource types for collections, versions, and now calendars.]
>>
>>
>> Nit: Versions aren't special resource types.
> 
> 
> Sorry, I meant MKWORKSPACE.

The alternative would have been just to use standard resources, but in 
that case RFC3253 would have had to define some new way to indicate that 
something indeed is a workspace.

>>> POST, in contrast, is a generic semantic that allows the resource
>>> to determine its implementation-specific effects.  POST to a
>>> collection means add a member.  POST to a PUT-able resource means
>>> an atomic append. POST to a messaging gateway means "post this".
>>
>>
>> Why can't a collection be PUT-able?
> 
> 
> It could have been, but MKCOL was defined instead (over my objection).

There is nothing in RFC2518 that prevents collections from being 
PUT-able (however the rational for not defining PUT on collections is a 
bit weird, see 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.7.2>).

>> OK, so that sounds to me like resources should fall into distinct 
>> categories:
>>
>> (A1) Collections vs (A2) Non-Collections
>> (B1) Put-able vs (B2) Non-Put-able
>>
>> - resources of type A1 would understand POST request as having 
>> "ADDMEMBER" semantics
>>
>> - resources of type A2 can (within reason) do anything they like with 
>> POST (as long as compliant to RFC2616)
>>
>> - resources of type B1 will allow PUT (as defined by RFC2616) and 
>> understand POST as "append" operation
>>
>> Let's consider a simple WebDAV server that supports only resources of 
>> types A1 and B1. What's the recommendation to do authoring operations 
>> beyond PUT on these resources? Define new methods (such as 
>> VERSION-CONTROL) or mint new related URLs to which existing methods 
>> can be applied?
> 
> 
> Different URLs (see, for example, how the configurable name "index"
> is a member of a collection and also the default response to GET
> on that collection).  How a PUT or POST or any other method applied
> to the collection is handled is just as configurable and may depend
> on other aspects of the request (like content-type, authentication,
> and more).  PUT is usually redirected to the index URL because
> namespace operations are typically done one name at a time rather

...when you say "typically", what implementation are you referring to? 
Is this implemented in Apache/mod_dav?

> than entire collections at a time, however that is dependent on the
> implementation: when a client does a PUT of an XML document to a
> JCR-backed implementation, it will create a collection (a document
> is just one view of the collection).
> 
> Each resource has an implementation and that implementation defines
> how the method impacts its state aside from what is already defined
> by virtue of HTTP's method semantics.  The reason we don't need
> ADDMEMBER is because POST already exists, a server must inspect
> the media type already, and none of the overlapping uses of POST
> are valid new members to add to a collection (soap envelopes or
> www/x-form-urlencoded).  It is therefore possible to say that POST

Interesting. Why wouldn't a SOAP envelope be a valid new collection 
member? And what about other potential content types resources could 
already implement for POST (that just happen to be proprietary)?

> has the add member effect on a webdav collection and be done.
> 
> ....Roy

Best regards, Julian

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

Received on Tuesday, 22 February 2005 23:39:42 UTC