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

Hi Julian,

--On September 22, 2008 5:42:54 PM +0200 Julian Reschke 
<julian.reschke@gmx.de> wrote:

> FYI -- this is an early draft of what I proposed in July
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0011.html>
> ).
>
> F

Looks good overall. Some comments:

1) When I first read the title I somehow thought this was talking about 
using POST to "create" collections. Perhaps change it to:

Using POST to add members to Web Distributed Authoring and Versioning 
(WebDAV)
                              Collections

2) I think this is a sufficiently worthy addition to WebDAV that using DAV: 
for the namespace is OK (just as we did with the current-user-principal 
property).

3) What about COPY/MOVE behavior? Is it OK to use the add-member property 
value as the Destination for COPY or MOVE when creating a new member in the 
destination? Or does a client instead have to user POST to create an empty 
resource first, then target that with the COPY/MOVE?

4) Something needs to be stated about error handling: e.g., "If there are 
pre-conditions related to creating a resource in the collection using a PUT 
request, then those same pre-conditions apply to the new POST request 
behavior, and the same DAV:error response body returned on failure". This 
would be a "catch-all" to allow protocols such as CalDAV, which restrict 
certain aspects of the data stored in collections, to simply return the 
same pre-condition failure information for POST as for PUT.

5) Is the server allowed to re-use new member URIs? i.e. /a/b.txt exists at 
some point, then is deleted. Is the server then allowed to use b.txt as a 
new member of /a/, or does the new member path segment have to be unique 
for the entire existence of that collection? If the member path segment is 
expected to be unique there should be some guidance to servers on how they 
might implement that (uuid's for instance).

6) It is also worth adding a note to client implementors stating that the 
server-generated member path segment is likely to not be suitable for 
direct presentation to end users, and instead clients should rely on the 
DAV:displayname property for presentation purposes.

7) Security consideration: "Servers MUST NOT derive the member path segment 
from the data being stored in the resource". This is important because you 
don't want server's leaking information in the URI that would not otherwise 
be visible (e.g. a user can PROPFIND the members but cannot read the 
content of the members - leaking content in the URI would be bad). Note 
this impacts how the server generates the member path segment. e.g. an md5 
hash of the data only may not be appropriate.

-- 
Cyrus Daboo

Received on Monday, 22 September 2008 16:27:04 UTC