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

Ok,

I have a new version ready that (hopefully) addresses all points that 
have been raised so far. See

	<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>

BR, Julian (planning to submit it tomorrow as -01)


Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On September 23, 2008 5:46:12 PM +0200 Julian Reschke 
> <[email protected]> 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.
>