RE: Gen-ART review of draft-daboo-webdav-sync-06

[<[e-mail]>]

Hi Cyrus,

The proposed changes for the two major issues look good to me:

[1] I'm pleased that the concern about adding elements turned out to be a wording issue.

[2] Your proposed new text is fine - it provides adequate notice/warning about possible
collection inconsistency, so I'm ok with not providing pseudo-code.

I'll leave the Downref issue ([3]) for you and Peter to work out with the IESG, and I'm
fine with continued use of your name in the examples if that's common practice.

Thanks,
--David

> -----Original Message-----
> From: Cyrus Daboo [mailto:[e-mail]]
> Sent: Monday, January 02, 2012 2:44 PM
> To: Black, David; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06
> 
> 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
>