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>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf