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

Hi Julian,

--On December 14, 2011 12:10:27 AM +0100 Julian Reschke 
<julian.reschke@gmx.de> wrote:

> On 2011-12-02 00:41, The IESG wrote:
>> ...
>
> Abstract
>
>     This specification defines an extension to WebDAV that allows
>     efficient synchronization of the contents of a WebDAV collection.
>
> -> Expand acronyms on first use.

Really, doesn't everyone know what WebDAV is by now :-) In any case fixed 
in my working copy.

>
>     Typically, the first time a client connects to the server it will
>     need to be informed of the entire state of the collection (i.e., a
>     full list of all member URIs that are currently in the collection).
>     That is done by the client sending an empty token value to the
>     server.  This indicates to the server that a full listing is
>     required.
>
> I think it would be more consistent with other specs not to send an empty
> token, but to send *no* token.

Existing implementations expect an empty sync-token element. I don't really 
see much difference either way on this, so would prefer to leave it as-is.

>     As an alternative, the client might choose to do its first
>     synchronization using some other mechanism on the collection (e.g.
>     some other form of batch resource information retrieval such as
>     PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those
>     defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav])
>
> The CardDAV reference will need to be updated...

Already fixed that one in my working copy.

>     To implement the behavior for this report a server needs to keep
>     track of changes to any member URIs and their mapped resources in a
>     collection (as defined in Section 3 of [RFC4918]).  This includes
>
> Actually, RFC 4918 defines "member URL"; maybe worth adjusting or
> pointing out it's the same.

Will make that change in my working copy. BTW "member URI" does appear in 
4918 in two places...

>     Marshalling:
>
>        The request URI MUST identify a collection.  The request body MUST
>        be a DAV:sync-collection XML element (see Section 6.1), which MUST
>        contain one DAV:sync-token XML element, and one DAV:prop XML
>        element, and MAY contain a DAV:limit XML element.
>
>        The request MUST include a Depth header with a value of "1" or
>        "infinity".
>
> This report definition is in conflict with the definition of the REPORT
> method in RFC 3253
> (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6>).
>
> Essentially, a report is applied to just the request URI (depth: 0 or no
> depth header field), the request URI and it's internal members (1) or all
> descendants (infinity).
>
> A report definition should define the response for the case of Depth: 0.
> The format for the other cases follows directly from RFC 3253:
>
> "If a Depth request header is included, the response MUST be a 207
> Multi-Status. The request MUST be applied separately to the collection
> itself and to all members of the collection that satisfy the Depth value.
> The DAV:prop element of a DAV:response for a given resource MUST contain
> the requested report for that resource."
>
> (Note that I have complained about this a long time ago,
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html>).
>
> To fix this, the report would need to define Depth: 0 processing on a
> collection to mean the changes just on that collection (which means
> membership changes, but not changes to member resources), and the other
> modes would then follow based on RFC 3253.
>
> It doesn't seem to be possible to make this change in a way that doesn't
> break existing implementations, as RFC 3253 requires the report response
> format to be well-formed XML (thus only one root element), and that
> format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop.
>
> Optimally, this should be fixed. If this can't be fixed I'd argue that
> the spec should be published as Informational, and that it should include
> an explanation of the incompatibilty (essentially requiring servers to
> special-case this report in case they already use a generic WebDAV REPORT
> framework).

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.

Given that I feel the sync report is vital for WebDAV operations, for in 
particular CalDAV and CardDAV, I want to ensure this draft proceeds as a 
standard, not informational. If you feel strongly about this use of Depth, 
in spite of my comments above, then I would be willing to make some 
changes, provided we also include a statement on backwards compatibility 
(i.e., in an appendix state that clients/servers MAY use/accept the old 
Depth approach). If we do that we would need to proceed as follows: state 
that sync report can only be used with Depth:0, add a new request header to 
define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). 
If we require Sync-Depth to be present, then we have a means for servers to 
detect old clients and handle Depth in a backwards compatible manner.

>        The response body for a successful request MUST be a DAV:
>        multistatus XML element, which MUST contain one DAV:sync-token
>
> Maybe s/one/a single/

Not sure why - "one DAV:xxx" is used in several places and I think is 
pretty clear.

>        ...
>
>     Preconditions:
>
>        (DAV:valid-sync-token): The DAV:sync-token element value MUST be a
>        valid token previously returned by the server.  A token can become
>        invalid as the result of being "out of date" (out of the range of
>        change history maintained by the server), or for other reasons
>        (e.g. collection deleted, then recreated, access control changes,
>        etc...).
>
> Does the sync-token need to originate from the same collection?

Yes of course. Perhaps changing the first sentence to:

The DAV:sync-token element value MUST be a valid token previously returned 
by the server for a synchronization report executed on the same 
request-URI.

>
> 3.3.  Depth behavior
>
>     Servers MUST support both Depth:1 and Depth:infinity behavior with
>     the DAV:sync-collection report.  Clients MUST include either a
>     Depth:1 or Depth:infinity request header with the DAV:sync-collection
>     report.
>
> See above; this contradicts the base definition of REPORT.

As stated above, I really don't think this is a contradiction of 3253.

>     In the case where a mapping between a member URI and the target
>     collection was removed, then a new mapping with the same URI created,
>     the member URI MUST be reported as changed and MUST NOT be reported
>     as removed.
>
> The client could tell that this happened if the DAV:resourceid property
> was included.
>
>     A member URI MUST be reported as changed if its mapped resource's
>     entity tag value (defined in Section 3.11 of [RFC2616]) has changed
>     since the request sync-token was generated.
>
> It should be mentioned that this only works well with resources that are
> not content-negotiated.

Unless the content negotiation was done as part of the original full sync 
request?

>     For example, consider a server that records changes using a
>     monotonically increasing integer to represent a "revision number" and
>     uses that quantity as the DAV:sync-token value (appropriately encoded
>     as a URI).  Assume the last DAV:sync-token used by the client was
>     "http://example.com/sync/10", and since then 15 additional changes
>     have occurred.  If the client executes a DAV:sync-collection request
>     with a DAV:sync-token of "http://example.com/sync/10", without a
>     limit the server would return 15 DAV:response elements and a DAV:
>
> Why 15? Is the assumption that any change to the server causes exactly
> one resource to change? What if there were 15 changes to the same
> resource?

OK, I will clarify the example to imply that the 15 changes are for 
separate resources. Proposed change:

From: and since then 15 additional changes have occurred
To: and since then 15 additional changes to different resources have 
occurred

>
>     <!ELEMENT multistatus (DAV:response*, DAV:responsedescription?,
>                            sync-token?) >
>
>     <!-- DAV:multistatus originally defined in RFC 4918, Section 14.16
>          but overridden here to add the DAV:sync-token element -->
>     <!-- DAV:response defined in RFC 4918, Section 14.24 -->
>     <!-- DAV:responsedescription defined in RFC 4918, Section 14.25 -->
>
> Why do we have DAV: prefixes on some of the DTD elements?
>
>

I haver removed the DAV: prefix in the actual <!ELEMENT ...> definitions, 
but kept them in the comments. OK?

-- 
Cyrus Daboo

Received on Wednesday, 14 December 2011 16:09:06 UTC