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

Hi Julian,

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

>> One thing this reminds me of: another reason why this POST may be needed
>> is if the server enforces a particular naming scheme on members. e.g., a
>> CalDAV server may require that all member path segments match the UID in
>> the calendar data, or match a record-id in its data store etc. In this
>> case the add-member behavior is required. So its not just the case of
>> "the client doesn't care to name members itself", but also this other
>> one. Probably worth adding a comment on this.
>> ...
>
> Well, if the server enforces a particular naming scheme, and does not
> support POST, then the client will need out-of-band information about the
> naming scheme, right? How would that work in practice?
>
> I think what's more common is that the server would *like* to enforce a
> naming scheme, but can't, as clients assume PUT will just work. Isn't
> that the situation for many CalDAV servers?

Yes.

> What I've added is
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-issues.html#
> issue.member-uri-content>):
>
> "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"

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

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

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


-- 
Cyrus Daboo

Received on Tuesday, 23 September 2008 15:30:50 UTC