- From: Ken Murchison <murch@andrew.cmu.edu>
- Date: Wed, 14 Dec 2011 12:29:18 -0500
- 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