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

Hi Julian,

--On September 22, 2008 7:19:30 PM +0200 Julian Reschke 
<julian.reschke@gmx.de> wrote:

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

So p:copy-member and p:move-member properties?

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.

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

If they are not guaranteed to be unique then we could run into client 
synchronizations issues if a resource is deleted and then a new one added, 
but created using the same name as the old one. That new resource is really 
meant to be totally different from the old, but any clients that had cached 
the old one and attempt to re-synchronize will end up doing so with the new 
resource. That could cause all kinds of nastiness when two ways sync'ing 
might be expected (e.g, disconnected CalDAV clients).

So, it might be worth pointing out that there are some use cases (two way 
sync) where it is best for a server to generate unique member names (or 
rather not re-use old, now deleted, member names).

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

Well, knowing that users X, Y and Z all had the same member name in their 
different collections would imply that they all had received copies of the 
same resource. In calendaring that could mean they were all invited to the 
same event. Being able to infer that might not be ideal. But then again 
giving someone the ability to PROPFIND a collection but not read the 
contents of the members is arguably leaking too much anyway (though I have 
had several arguments about this with colleagues who disagree).

-- 
Cyrus Daboo

Received on Monday, 22 September 2008 18:53:58 UTC