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

Peter Saint-Andre <> Thu, 19 January 2012 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26E8B21F8678; Thu, 19 Jan 2012 08:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.658
X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aL4tqjya32ZD; Thu, 19 Jan 2012 08:53:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2F09E21F8675; Thu, 19 Jan 2012 08:53:26 -0800 (PST)
Received: from (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 2F95A40058; Thu, 19 Jan 2012 10:02:52 -0700 (MST)
Message-ID: <>
Date: Thu, 19 Jan 2012 09:53:25 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
References: <> <250FD273F8360ED86D73260F@cyrus.local> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.4
OpenPGP: url=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [Gen-art] Gen-ART review of draft-daboo-webdav-sync-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jan 2012 16:53:29 -0000

Hi David,

The text changes that Cyrus proposed have been incorporated into a
revised I-D:

Please let us know if the new version accurately reflects your
discussion with the authors.



On 1/2/12 12:55 PM, 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 []
>> Sent: Monday, January 02, 2012 2:44 PM
>> To: Black, David;;;
>> Cc:
>> 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 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