W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2011

Re: Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 14 Dec 2011 18:19:11 +0100
Message-ID: <4EE8DA8F.4020808@gmx.de>
To: Ken Murchison <murch@andrew.cmu.edu>
CC: Cyrus Daboo <cyrus@daboo.name>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>
On 2011-12-14 18:01, Ken Murchison wrote:
> Cyrus Daboo wrote:
>> I am not convinced the use of Depth in sync report is violating the
>> definition in 3253. In some ways it is a matter of how you look at the
>> sync. Your viewpoint is that the report asks the collection for its
>> changes - in that case, yes, Depth:0 would apply. The other view is
>> that the report asks each of the child resources to list their change
>> status, in which case Depth:1 and Depth:infinity also makes sense.
>> Which viewpoint is taken probably depends on actual implementation
>> rather than any perceived protocol restrictions.
> My $.02:
> I look the sync report as a filtered query for properties (e.g.
> CALDAV:calendar-query), with the filter being "only give me a
> DAV:response if the resource has been changed/removed since the
> specified sync-token".
> A Depth of 1 or infinity gives us exactly what is specified in the draft.
> A Depth of 0 refers to the collection itself, and assuming it exists,
> the DAV:multistatus response may or may not include a single
> DAV:response element, depending on whether the server maintains an
> entity tag on the collection which changes with its membership. In
> either case, the sync-token is returned per the extended grammar in 6.3.
> So, a sync-collection report with a depth of 0 might simply return the
> following:
> <D:multistatus>
> <D:sync-token>http://example.com/ns/sync/1234</D:sync-token>
> </D:multistatus>
> Does this make sense, or is my logic completely convoluted?

If this was designed from scratch, it wouldn't be using multistatus, but 
would include the properties of the collection (if changed).

   ... other collection props the report asked for ...
Received on Wednesday, 14 December 2011 17:19:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:39 UTC