Re: [Gen-art] Gen-ART review of draft-daboo-webdav-sync-06

[Cyrus Daboo <[e-mail]>]

Hi David,
Thank you for your review. Comments inline:

--On December 27, 2011 11:07:49 PM -0500 [e-mail] wrote:

> [1] -Major- Section 3.5 does not appear to cover the case reporting added
> elements on a subsequent synchronization.  The problem may be that the
> word "changed" as used in Section 3.5.1 is assumed to cover adding an
> element - if so, that's not a good assumption, and the addition case
> should be explicitly called out in the title and body of Section 3.5.1.

The first sentence of 3.5.1 is:

    A member URL MUST be reported as changed if it has been mapped as a
    member of the target collection since the request sync-token was
    generated.

The term "mapped" implies creation/addition of a new resource in this case. 
That may not be obvious to anyone who is not intimately familiar with 
WebDAV terminology here, so I propose changing that to:

    A member URL MUST be reported as changed if it has been newly mapped as
    a member of the target collection since the request sync-token was
    generated (e.g., when a new resource has been created as a child of the
    collection).

> [2] -Major- The operations to retrieve changed members of a collection
> are not atomic wrt the operation that obtains a report on what has
> changed; collection changes can occur between retrieving the report and
> retrieving the changed elements or while retrieving the changed elements.
> For this reason, simply obtaining a change report and then retrieving the
> elements that have changed according to the report may not result in a
> consistent (e.g., as of a point in time) copy of a collection.  I believe
> that this absence of atomicity is a WebDAV "feature", as opposed to a
> "bug", but I believe that this behavior and what to do about it should be
> discussed in the draft.  I suggest the following, possibly to the end of
> section 3.1
>
> i) Add a sentence or two to warn that obtaining a change report and then
> retrieving the changed elements may not result in a consistent local
> version of the collection if nothing else is done because changes may
> have occurred in the interim.
>
> ii Add a discussion of how to ensure that a local copy of the collection
> is consistent. The basic idea is to re-presented the sync token for that
> copy to the server after the changed elements have been retrieved; the
> local copy is consistent if the server reports that there have been no
> changes.  Some pseudo-code may help, e.g.:
>
> 	GetSyncCollectionReport(in token, out newtoken, out report);
> 	while (ReportHasChangedItems(report) {
> 		GetChangedItems(report)
> 		token = newtoken;
> 		GetSyncCollectionReport(in token, out newtoken, out report);
> 	}
>
> Actual code should include a counter that counts the number of iterations
> of the while loop and exits with an error if the number of iterations
> exceeds some limit; that error exit implies that the collection is
> (currently) changing too rapidly to obtain a consistent local version.

Good point. I agree that this deserves some additional text to clarify this 
situation. However, I would rather not go into too much detail of how 
clients "re-sync" in cases like this as there are a bunch of different ways 
that could happen each of which depends on exactly what the client is 
trying to do (e.g., in a lot of cases clients will be doing two-way syncs 
so will need to reconcile server and local changes within the loop you 
propose above - the details of that are not in scope for this 
specification). What I propose is the addition of the following paragraph 
to the end of Section 3.1:

    Typically, a client will use the synchronization report to retrieve the
    list of changes, and will follow that with requests to retrieve the
    content of changed resources. It is possible that additional changes to
    the collection could occur between the time of the synchronization
    report and resource content retrieval, which could result in an
    inconsistent view of the collection. When clients use this method of
    synchronization, they need to be aware that such additional changes
    could occur, and track them through normal means (e.g., differences
    between the ETag values returned in the synchronization report and
    those returned when actually fetching resource content), conditional
    requests as described in Section 5, or repeating the synchronization
    process until no changes are returned.

> [3] -Minor- idnits 2.12.12  reports a Downref to RFC 5842.  Please
> consult your Area Director (Peter Saint-Andre) to determine what to do
> about this Downref (it requires attention, but may not require changes to
> the draft).

Working with IESG on this one.

> Nit: I suggest not using the author's own name (cyrusdaboo) in the
> examples.  Someone may copy the code from the resulting RFC.

This has been common practice in most of the other CalDAV/CardDAV RFCs I 
have worked on and has not been the source of any problems, so I would 
rather leave this unchanged. If there is an official IETF policy on using 
"real names" in examples, then I would be happy to change to follow that, 
but I am not aware of anything like that.

> Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been
> published as RFC 6352; the RFC Editor will correct this if a new version
> of the draft is not required for other reasons.

Fixed in my working copy.


-- 
Cyrus Daboo