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

Hi Cyrus,

that may have been the world record for the fastest feedback after an 
Internet Draft being published!

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On September 22, 2008 5:42:54 PM +0200 Julian Reschke 
> <[email protected]> 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

Actually, it was supposed to say that. Thanks for pointing this out (as 
usually, current edits are at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>).

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

Thanks.

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

The former would only work when the server actually has minted a 
separate URI (which I think will be the less frequent case).

That being said, that COPY/MOVE functionality could of course be exposed 
using *another* URI.

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

Sounds good.

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

I don't expect it to be unique. Of course a collection *could* have that 
property, but that would need to be exposed differently (DAV:resourcetype?).

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

That depends. For instance, if the client specified a Slug, and the 
server used that, the resulting URI actually is expected to work ok for 
display 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 

Good catch.

> path segment. e.g. an md5 hash of the data only may not be appropriate.

...how could that one leak information?

BR, Julian