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

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Dec 2011 14:12:26 +0100

(FYI)

-------- Original Message --------
Subject: Last Call: <draft-daboo-webdav-sync-06.txt> (Collection 
Synchronization for WebDAV) to Proposed Standard
Date: Thu, 01 Dec 2011 15:41:41 -0800
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:
- 'Collection Synchronization for WebDAV'
   <draft-daboo-webdav-sync-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-12-29. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

    This specification defines an extension to WebDAV that allows
    efficient synchronization of the contents of a WebDAV collection.

Editorial Note (To be removed by RFC Editor before publication)

    Please send comments to the Distributed Authoring and Versioning
    (WebDAV) working group at <mailto:[email-masked]>, which may be
    joined by sending a message with subject "subscribe" to
    <mailto:[email-masked]>.  Discussions of the WEBDAV
    working group are archived at
    <http://lists.w3.org/Archives/Public/w3c-dist-auth/>.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 00:10:27 +0100

On 2011-12-02 00:41, The IESG wrote:
> ...

Abstract

-> Expand acronyms on first use.

    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.

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

    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.

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

       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/

       ...

    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?

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.

    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.

    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?

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