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

On 2011-12-14 17:06, Cyrus Daboo wrote:
> 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.

Just being "pro-active" :-). The less happens ion AUTH48, the better.

>> 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.

Would be interesting to know how they treat missing sync tokens.

> ...
>> 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...

Errata, errata!

>> 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

It does.

RFC 3253 defines the response format for Depth 0, and then states how 
the format for Depth > 0 is derived from that; essentially by packaging 
into <multistatus>.

This means that reports that do not support Depth 0 can not be defined.

It also means that a report that uses <multistatus> for Depth 0, and 
which supports depths > 0, will have to packages <multistatus> inside 
<multistatus>.


> 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.

What Depth 0 means is just a matter of definition. If you want to make 
Depth 0 mean "request-URI and all of it's direct members", that's fine. 
It just will give funny results when you use it with other Depths *and* 
follow the RFC 3253 definition in these cases.

> 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.

Not happy having to add a new header field just for that. A simpler 
approach might be to just assign a different report name, and then allow 
all depths.


>> 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.

I was confused for a moment because I read it to be one token per 
response element.

>> ...
>>
>> 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.

+1

(I was asking because in many cases the token will be the same 
everywhere, and clients might think this is always the case)

> ...
>> 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?

How would that work?

For instance, the common case for Conneg is using Accept:, but Accept: 
on REPORT specifies the expected media type for the REPORT response.

Yes, that's a problem with WebDAV in general.

>> 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

+1

>> <!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?

OK.

Best regards, Julian

Received on Wednesday, 14 December 2011 16:29:53 UTC