Hi David, The text changes that Cyrus proposed have been incorporated into a revised I-D: http://tools.ietf.org/rfcdiff?url2=draft-daboo-webdav-sync-07 Please let us know if the new version accurately reflects your discussion with the authors. Thanks! Peter On 1/2/12 12:55 PM, david.black@xxxxxxx wrote: > 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:cyrus@xxxxxxxxxx] >> Sent: Monday, January 02, 2012 2:44 PM >> To: Black, David; arnaud.quillaud@xxxxxxxxxx; gen-art@xxxxxxxx; ietf@xxxxxxxx >> Cc: stpeter@xxxxxxxxxx >> 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 david.black@xxxxxxx 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 >> > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf