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:01:37 -0500
Message-ID: <4EE8D671.9040607@andrew.cmu.edu>
To: Cyrus Daboo <cyrus@daboo.name>
CC: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>
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?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Wednesday, 14 December 2011 17:02:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 December 2011 17:02:55 GMT