[Gen-art] Gen-ART review of draft-daboo-webdav-sync-07
<david.black@emc.com> Thu, 19 January 2012 22:54 UTC
Return-Path: <david.black@emc.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01A721F85D0; Thu, 19 Jan 2012 14:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.833
X-Spam-Level:
X-Spam-Status: No, score=-108.833 tagged_above=-999 required=5 tests=[AWL=1.766, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uEN0QJ1scK3; Thu, 19 Jan 2012 14:54:50 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2621F85C9; Thu, 19 Jan 2012 14:54:49 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0JMsYFH024105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 17:54:39 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 19 Jan 2012 17:54:15 -0500
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0JMsDwv006681; Thu, 19 Jan 2012 17:54:13 -0500
Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 19 Jan 2012 17:54:13 -0500
From: david.black@emc.com
To: stpeter@stpeter.im
Date: Thu, 19 Jan 2012 17:54:12 -0500
Thread-Topic: Gen-ART review of draft-daboo-webdav-sync-07
Thread-Index: AczWywMBbl5mbsctTV2kg2BDvHgIIwAMK4XA
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1011@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> <250FD273F8360ED86D73260F@cyrus.local> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> <4F184A85.60604@stpeter.im>
In-Reply-To: <4F184A85.60604@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: cyrus@daboo.name, gen-art@ietf.org, arnaud.quillaud@oracle.com, ietf@ietf.org
Subject: [Gen-art] Gen-ART review of draft-daboo-webdav-sync-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2012 22:54:51 -0000
Hi Peter, Yes, the new -07 of this draft is fine, as it resolves issues [1] and [2] as agreed with the authors, and also resolves issue [3] by changing RFC 5842 from a normative reference to an informative reference. That change is fine with me, as the references to RFC 5842 are all for examples that explain some of the synchronization functionality - it is not necessary to implement any of the requests listed as being specified in RFC 5842 in order to implement the synchronization functionality. Thanks, --David > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Thursday, January 19, 2012 11:53 AM > To: Black, David > Cc: cyrus@daboo.name; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 > > 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@emc.com 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@daboo.name] > >> Sent: Monday, January 02, 2012 2:44 PM > >> To: Black, David; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf.org > >> Cc: stpeter@stpeter.im > >> 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@emc.com 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 > >> > > >
- [Gen-art] Gen-ART review of draft-daboo-webdav-sy… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Cyrus Daboo
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Peter Saint-Andre
- [Gen-art] Gen-ART review of draft-daboo-webdav-sy… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Russ Housley