ietf
[Top] [All Lists]

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

2011-12-15 16:19:50
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>