Re: I-D Action:draft-reschke-webdav-post-00.txt

Cyrus Daboo wrote:
> ...
>> "As a matter of fact, letting the server choose the member URI not only
>> is a simplification for certain types of clients, but can also reduce the
>> complexity of the server (in that it doesn't need to persist an
>> additional client-supplied identifier where the it already has an
> 
>                                              ^^^ remove "the"

Fixed (thanks!).

>> internal one like a UUID or a primary key)."
>>
>> That said, I think I'm ready to submit a new draft soon; comments on
>> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>
>> appreciated.
> 
> So one option for the server to enforce its naming scheme would be to 
> require POST by the client to create new resources rather than allowing 
> PUT/COPY/MOVE to do so. However there is no way fort a client to 
> discover that such a restriction might be in place other than getting a 
> 403. How about a new pre-condition code for that so that the server can 
> indicate "DAV:only-post-allowed-to-create-new-members" to the client? 
> With perhaps a more compact name!

Actually, it would be discoverable through OPTIONS.

When /collection does not allow PUT to add new members, an OPTIONS 
request on /collection/a should not return "PUT" in the Allow header.

That being said, stating that these kinds of collections could exist, 
and defining a precondition name certainly is a good idea.

> This brings up another question: presumably the DAV:bind privilege is 
> required on the collection for the new POST ;add-member behavior to be 
> allowed (just as it would be required for PUT creating a new member). I 
> think we therefore need a statement in Security Considerations:
> 
> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is 
> required to be granted on the collection resource in which the new 
> member resource is being created. If this privilege is denied or not 
> present, the POST request MUST fail."

Yes, although I'd move that into a "Relation to WebDAV ACL" section.

> Another question: there is no restriction on what p:add-member URI can 
> be? e.g. if I have the collection "/a/b/" can the p:add-member be 
> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is

I thought that was already clear; maybe I should have chosen a different 
URI :-)

> possible it should be called out, as the behavior might be somewhat 
> unexpected for clients. It might even be the case that the p:add-member 
> URI is on a different server (e.g. new member items in a collection need 
> "approval" from some other service). The interaction with WebDAV ACL in 

It seems that that kind of redirection would need a different mechanism. 
Let's not make things more complicated than they need to be.

> this case would need to be clear - i.e. what privileges are required on 
> the p:add-member URI?

I think it would be sufficient to state the ACL requirements in terms of 
DAV:bind on the "real" collection. The add-member URI in general could 
me a non-WebDAV resource, so talking about WebDAV ACLs really doesn't 
make sense here.

BR, Julian