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