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

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

Potentially.

My primary concern was to allow WebDAV collections to do something 
sensible with POST which is compatible with AtomPub, and which also 
addresses a real need that we've seen for instance with CalDAV. This 
turned out to be trivial.

I'm concerned to add something that's not as easy to achieve, and where 
I'm not sure about what the use case is.

Note that Microsoft does define an extension header for things like 
that, essentially allowing the server to "rename" the Destination URI. 
Maybe it's worthwhile looking at that for COPY/MOVE.

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

Of course, that's a major reason to do that. I'll add that to the 
Introduction.

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

You could use DAV:resource-id to distinguish them.

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

Agreed, but doesn't that consideration belong into the specification 
that defines that specific collection's behavior? (such as vcarddav?)

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

Thanks for the example.

And yes, whether non-accessible members of a collection should show up 
upon PROPFIND is an interesting question, and we're not going to solve 
that here.

(I personally believe that if the presence of a collection member's name 
already leaks out information, you really should restrict the read 
access to the parent collection...)

BR, Julian

Received on Monday, 22 September 2008 19:09:59 UTC