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: Ken Murchison <murch@andrew.cmu.edu>
Date: Wed, 14 Dec 2011 12:29:18 -0500
Message-ID: <4EE8DCEE.6020602@andrew.cmu.edu>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Cyrus Daboo <cyrus@daboo.name>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>
Julian Reschke wrote:
> 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).
> <D:sync-result>
>   ... other collection props the report asked for ...
>   <<D:sync-token>http://example.com/ns/sync/1234</D:sync-token>
> </D:sync-result>

I don't necessarily see a problem with sync report using multistatus, 
but perhaps the sync-token should be returned in a prop response element 
for the collection rather than as an added element of multistatus.

Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Wednesday, 14 December 2011 17:32:34 UTC

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