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

Hi Julian,

--On September 23, 2008 5:46:12 PM +0200 Julian Reschke 
<julian.reschke@gmx.de> wrote:

>> "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 :-)

A couple of different examples would help make it clear.

>> 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.

OK, then let's explicitly state that the add-member URI must not be on a 
different server.

>> 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.

OK, makes sense.

-- 
Cyrus Daboo

Received on Tuesday, 23 September 2008 16:05:29 UTC