From lear@cisco.com Mon Jan 6 08:39:10 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EACE1AE0C6 for ; Mon, 6 Jan 2014 08:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2esHgOQZFpg for ; Mon, 6 Jan 2014 08:39:08 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 688E11AE069 for ; Mon, 6 Jan 2014 08:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1587; q=dns/txt; s=iport; t=1389026340; x=1390235940; h=message-id:date:from:mime-version:to:subject; bh=pnc9HzmDoRjQp7k7Jm8lKWeeWTVTgrJSak+0ZrBZ/wo=; b=Gn/aH3Y4V+Of5efyYTXBDtWY3KavfbjnBtiUtiPnYc+hk7dG5aZxNXTO fARD64x5PNaqNZ+umAtrcQ+bA2dbr2ggLUFbmOz5HX2613OpGic/GER/E lMMb8k5Gwl6/ONRwAe7Yf2ZdsHOb8KP8gnMXcjbUq5xB0Cbdx4SbMDhUU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPLaylKQ/khM/2dsb2JhbABYgwuEC7dUFnSCHDMEUR8BHRYLAgsDAgECASsgDQgBAYgAmlOPEZlWF5IFgUgEmBeSFYMuOw X-IronPort-AV: E=Sophos;i="4.95,613,1384300800"; d="scan'208,217";a="3250338" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 06 Jan 2014 16:38:59 +0000 Received: from mctiny.local ([10.61.170.245]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s06Gcwvg016252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Jan 2014 16:38:59 GMT Message-ID: <52CADC24.2000304@cisco.com> Date: Mon, 06 Jan 2014 17:39:00 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: qresync WG X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------030801030804080306030703" Subject: [imapext] fyi- status of draft-ietf-qresync-5162bis X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:39:10 -0000 This is a multi-part message in MIME format. --------------030801030804080306030703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This one was with me until today, as doc shepherd. I've completed my review, and asked Alexey to make a small number of changes. Specifically: * Address idnits. * Include reasoning behind update status line for various RFCs * Correct reference to 3.1.1.2 (of what?) in ABNF for status-att-val * Confirm that Erratum 1810 is now irrelevant (I think it is). * Informative->Normative for RFC2683 This means I'm asking for an updated draft. Eliot --------------030801030804080306030703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit This one was with me until today, as doc shepherd. I've completed my review, and asked Alexey to make a small number of changes. Specifically:

Address idnits.
Include reasoning behind update status line for various RFCs
Correct reference to 3.1.1.2 (of what?) in ABNF for status-att-val
Confirm that Erratum 1810 is now irrelevant (I think it is).
Informative->Normative for RFC2683

This means I'm asking for an updated draft.

Eliot

--------------030801030804080306030703-- From internet-drafts@ietf.org Tue Jan 7 03:40:51 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A6B1ADF74; Tue, 7 Jan 2014 03:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-DqIFy9aIrW; Tue, 7 Jan 2014 03:40:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 032761AD9B8; Tue, 7 Jan 2014 03:40:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 03:40:49 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 11:40:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extensions for Conditional STORE Operation o= r Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resync= hronization (QRESYNC) Authors : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-07.txt Pages : 50 Date : 2014-01-07 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. The Conditional Store facility provides a protected update mechanism for message state information -- for example, the mechanism can be used to guarantee that only one client can change message state at any time -- and a mechanism for requesting only changes to message state. This document additionally defines another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. This document obsoletes RFC 4551 and RFC 5162. It updates RFC 4315, RFC 3501 and RFC 2683. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Tue Jan 7 03:46:23 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746EF1ADF72 for ; Tue, 7 Jan 2014 03:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycfyADgX0NHy for ; Tue, 7 Jan 2014 03:46:21 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 693C61ADF22 for ; Tue, 7 Jan 2014 03:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1389095126; d=isode.com; s=selector; i=@isode.com; bh=wme5fJEfPAScm6P36oahFEhaZ1OUjV1h4ovNUJavCss=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Ow6FN2wG2jFhpFlpXwvryHckJuAEK8k5DbraLnqICMhzrPQwgjk1D1CjnaT11bYFrFn+0E XzXoZxQakqhUzmdDPsju9enQ4mqeHRgCD6/tVvAIlBQ+rKPwo87e0fu03B/zfCdaxMSoGp GoRKL35MfNa64NdaOi3ugQgan44Ez4U=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Jan 2014 11:45:25 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52CBE8D4.7000107@isode.com> Date: Tue, 07 Jan 2014 11:45:24 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: qresync WG References: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> In-Reply-To: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 11:46:23 -0000 On 07/01/2014 11:40, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-07 This version updates Abstract/Introduction to be more compact and to not contain normative requirements. It also addresses ID-nits and erratum 1810 from Timo which I forgot to address earlier. From lear@cisco.com Tue Jan 7 04:44:22 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355BF1ADFCA for ; Tue, 7 Jan 2014 04:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hszGOidmxgad for ; Tue, 7 Jan 2014 04:44:20 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 66AE91ADBD4 for ; Tue, 7 Jan 2014 04:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9315; q=dns/txt; s=iport; t=1389098651; x=1390308251; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=L2wWkKgmZ79hQIEUK6wvB3i0ooaRBeHGbKc0591i7Po=; b=L0WI5v4rfltMfyZogfW+zp6mj9BHvHktey1IAiu1j3Q/y9EfM6cUH1PB KI6uAKyRwS+e04oOyuObScRa3ws267/TDKyTFUfKyAui4Hy1x3OlsEnyx CXhWHpGAPUkxnCyl+oy2r9Xip0MxN5NFYwhPZxt4n5e+cIQxTNjhCqgsB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAEj2y1KQ/khL/2dsb2JhbABZgws4T4MEthdPgQ8WdIIlAQEBBAEBASBLChELGAkWCwICCQMCAQIBFRYaBgEMBgIBAQWHewgFqhSaIheOGBlagm+BSASYF4EwkGWDLjuBNQ X-IronPort-AV: E=Sophos;i="4.95,618,1384300800"; d="scan'208,217";a="2617276" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 07 Jan 2014 12:44:09 +0000 Received: from mctiny.local ([10.61.211.253]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s07Ci7h4025960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 12:44:08 GMT Message-ID: <52CBF697.9010508@cisco.com> Date: Tue, 07 Jan 2014 13:44:07 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexey Melnikov , qresync WG References: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> <52CBE8D4.7000107@isode.com> In-Reply-To: <52CBE8D4.7000107@isode.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------090301040805030509000101" Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 12:44:22 -0000 This is a multi-part message in MIME format. --------------090301040805030509000101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Alexey, Thanks for making these changes. I'm sorry. I need one more change. The proto write-up is pretty clear about updates. It says the following: > * If publication of this document changes the status of any existing > RFCs, are those RFCs listed on the title page header, and are the > changes listed in the abstract and discussed (explained, not just > mentioned) in the introduction? I propose the following textual changes to the abstract to sort all of this: OLD: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. The Conditional Store facility provides a protected update mechanism for message state information -- for example, the mechanism can be used to guarantee that only one client can change message state at any time -- and a mechanism for requesting only changes to message state. This document additionally defines another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. This document obsoletes RFC 4551 and RFC 5162. It updates RFC 4315, RFC 3501 and RFC 2683. New: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, in when these extensions are used, other mechanisms are updated. In particular, the line length recommendation in RFC 2863 is modified, the UID EXPUNGE command from RFC 4315 is modified, and the behavior of EXPUNGE from RFC 3501 is modified. Eliot On 1/7/14 12:45 PM, Alexey Melnikov wrote: > On 07/01/2014 11:40, internet-drafts@ietf.org wrote: >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-07 > This version updates Abstract/Introduction to be more compact and to > not contain normative requirements. > It also addresses ID-nits and erratum 1810 from Timo which I forgot to > address earlier. > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > > --------------090301040805030509000101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Alexey,

Thanks for making these changes. I'm sorry. I need one more change. The proto write-up is pretty clear about updates. It says the following:

> * If publication of this document changes the status of any existing
>   RFCs, are those RFCs listed on the title page header, and are the
>   changes listed in the abstract and discussed (explained, not just
>   mentioned) in the introduction?

I propose the following textual changes to the abstract to sort all of this:

OLD:

   Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
   a common IMAP mailbox.  Examples include different clients working on
   behalf of the same user, and multiple users accessing shared
   mailboxes.  These clients need a mechanism to efficiently synchronize
   state changes for messages within the mailbox.

   The Conditional Store facility provides a protected update mechanism
   for message state information -- for example, the mechanism can be
   used to guarantee that only one client can change message state at
   any time -- and a mechanism for requesting only changes to message
   state.

   This document additionally defines another IMAP extension, Quick
   Resynchronization, which builds on the Conditional Store extension to
   provide an IMAP client the ability to fully resynchronize a mailbox
   as part of the SELECT/EXAMINE command, without the need for
   additional server-side state or client round-trips.

   This document obsoletes RFC 4551 and RFC 5162.  It updates RFC 4315,
   RFC 3501 and RFC 2683.

New:

   Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
   a common IMAP mailbox.  Examples include different clients working on
   behalf of the same user, and multiple users accessing shared
   mailboxes.  These clients need a mechanism to efficiently synchronize
   state changes for messages within the mailbox.

   Initially defined in RFC 4551, The Conditional Store facility provides
   a protected update mechanism for message state information and a 
   mechanism for requesting only changes to message state.  This memo
   updates that mechanism and obsoletes RFC 4551, based on operational
   experience.

   This document additionally updates another IMAP extension, Quick
   Resynchronization, which builds on the Conditional Store extension to
   provide an IMAP client the ability to fully resynchronize a mailbox
   as part of the SELECT/EXAMINE command, without the need for
   additional server-side state or client round-trips.  Hence this memo
   obsoletes RFC 5162.

   Finally, in when these extensions are used, other mechanisms are
   updated.  In particular, the line length recommendation in RFC 2863
   is modified, the UID EXPUNGE command from RFC 4315 is modified, and
   the behavior of EXPUNGE from RFC 3501 is modified.


Eliot

On 1/7/14 12:45 PM, Alexey Melnikov wrote:

On 07/01/2014 11:40, internet-drafts@ietf.org wrote:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-07

This version updates Abstract/Introduction to be more compact and to not contain normative requirements.
It also addresses ID-nits and erratum 1810 from Timo which I forgot to address earlier.

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--------------090301040805030509000101-- From internet-drafts@ietf.org Tue Jan 7 05:48:41 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CE1AE046; Tue, 7 Jan 2014 05:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0cUIKMH1KVp; Tue, 7 Jan 2014 05:48:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 783D21ADF66; Tue, 7 Jan 2014 05:48:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107134839.21725.41795.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 05:48:39 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-08.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 13:48:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extensions for Conditional STORE Operation o= r Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resync= hronization (QRESYNC) Authors : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-08.txt Pages : 50 Date : 2014-01-07 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, when these extensions are used, other mechanisms are updated. In particular, the line length recommendation in RFC 2863 is modified, the UID EXPUNGE command from RFC 4315 is modified, and the behavior of STORE/UID STORE/FETCH/UID FETCH/EXPUNGE commands from RFC 3501 is modified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Tue Jan 7 05:51:00 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC311AE038 for ; Tue, 7 Jan 2014 05:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70rT0gdFGwQw for ; Tue, 7 Jan 2014 05:50:59 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC61AE042 for ; Tue, 7 Jan 2014 05:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1389102649; d=isode.com; s=selector; i=@isode.com; bh=tg4S+9gOZHjohN66g2gDLYBJkrE6P8mJPjVUvFoteeU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=XZCwXD7HWkrsqC2vyZJQGBxvvp+r0kwmJffoedGZhNnvCvpZuvJXXDKmtg/JqCaJZQ1RYJ igrJn1ro5FX7af4hP9YSUzQSWwThymUOB+fkPDKAWWsLWWihvg+Ze0FXflrJOQIO/kRokS TRQRQnZSfM/ozxpPIT7yF1n2GENEWDg=; Received: from [172.16.1.224] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Jan 2014 13:50:49 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52CC0639.2080106@isode.com> Date: Tue, 07 Jan 2014 13:50:49 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Eliot Lear References: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> <52CBE8D4.7000107@isode.com> <52CBF697.9010508@cisco.com> In-Reply-To: <52CBF697.9010508@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030302020508010200090800" Cc: qresync WG Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 13:51:00 -0000 This is a multi-part message in MIME format. --------------030302020508010200090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/01/2014 12:44, Eliot Lear wrote: > Hi Alexey, Hi Eliot, > Thanks for making these changes. I'm sorry. I need one more change. > The proto write-up is pretty clear about updates. It says the following: > > > * If publication of this document changes the status of any existing > > RFCs, are those RFCs listed on the title page header, and are the > > changes listed in the abstract and discussed (explained, not just > > mentioned) in the introduction? > > I propose the following textual changes to the abstract to sort all of > this: > > OLD: > > The Conditional Store facility provides a protected update mechanism > for message state information -- for example, the mechanism can be > used to guarantee that only one client can change message state at > any time -- and a mechanism for requesting only changes to message > state. > > This document additionally defines another IMAP extension, Quick > Resynchronization, which builds on the Conditional Store extension to > provide an IMAP client the ability to fully resynchronize a mailbox > as part of the SELECT/EXAMINE command, without the need for > additional server-side state or client round-trips. > > This document obsoletes RFC 4551 and RFC 5162. It updates RFC 4315, > RFC 3501 and RFC 2683. > > New: > > > Initially defined in RFC 4551, The Conditional Store facility provides > a protected update mechanism for message state information and a > mechanism for requesting only changes to message state. This memo > updates that mechanism and obsoletes RFC 4551, based on operational > experience. > > This document additionally updates another IMAP extension, Quick > Resynchronization, which builds on the Conditional Store extension to > provide an IMAP client the ability to fully resynchronize a mailbox > as part of the SELECT/EXAMINE command, without the need for > additional server-side state or client round-trips. Hence this memo > obsoletes RFC 5162. > > Finally, in when these extensions are used, other mechanisms are > updated. In particular, the line length recommendation in RFC 2863 > is modified, the UID EXPUNGE command from RFC 4315 is modified, and > the behavior of EXPUNGE from RFC 3501 is modified. I slightly modified the last paragraph, as it was not quite right. But otherwise I've used your text. -08 posted. --------------030302020508010200090800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 07/01/2014 12:44, Eliot Lear wrote:

Hi Alexey,

Hi Eliot,

Thanks for making these changes. I'm sorry. I need one more change. The proto write-up is pretty clear about updates. It says the following:

> * If publication of this document changes the status of any existing
>   RFCs, are those RFCs listed on the title page header, and are the
>   changes listed in the abstract and discussed (explained, not just
>   mentioned) in the introduction?

I propose the following textual changes to the abstract to sort all of this:

OLD:

   The Conditional Store facility provides a protected update mechanism
   for message state information -- for example, the mechanism can be
   used to guarantee that only one client can change message state at
   any time -- and a mechanism for requesting only changes to message
   state.

   This document additionally defines another IMAP extension, Quick
   Resynchronization, which builds on the Conditional Store extension to
   provide an IMAP client the ability to fully resynchronize a mailbox
   as part of the SELECT/EXAMINE command, without the need for
   additional server-side state or client round-trips.

   This document obsoletes RFC 4551 and RFC 5162.  It updates RFC 4315,
   RFC 3501 and RFC 2683.

New:


   Initially defined in RFC 4551, The Conditional Store facility provides
   a protected update mechanism for message state information and a 
   mechanism for requesting only changes to message state.  This memo
   updates that mechanism and obsoletes RFC 4551, based on operational
   experience.

   This document additionally updates another IMAP extension, Quick
   Resynchronization, which builds on the Conditional Store extension to
   provide an IMAP client the ability to fully resynchronize a mailbox
   as part of the SELECT/EXAMINE command, without the need for
   additional server-side state or client round-trips.  Hence this memo
   obsoletes RFC 5162.

   Finally, in when these extensions are used, other mechanisms are
   updated.  In particular, the line length recommendation in RFC 2863
   is modified, the UID EXPUNGE command from RFC 4315 is modified, and
   the behavior of EXPUNGE from RFC 3501 is modified.

I slightly modified the last paragraph, as it was not quite right. But otherwise I've used your text. -08 posted.

--------------030302020508010200090800-- From jkt@flaska.net Tue Jan 7 07:22:32 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE21ADF67 for ; Tue, 7 Jan 2014 07:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX-86kp-6jVw for ; Tue, 7 Jan 2014 07:22:30 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id D71631ADF66 for ; Tue, 7 Jan 2014 07:22:29 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id C86EA60064; Tue, 7 Jan 2014 16:22:16 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 07 Jan 2014 16:22:17 +0100 User-Agent: Trojita/v0.3.96-177-gad66067; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <50cf231f-4bd5-4a40-b2fa-a6dd4ffa5c18@flaska.net> In-Reply-To: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> References: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 15:22:32 -0000 Hi Alexey, I have tried to split the VANISHED and VANISHED (EARLIER) into two separate=20= sections, as discussed in December. Sorry for this rather long delay. The changes live at [1]. If you push the -08 version, I can easily rebase=20 these changes on top of that. Hope it isn't too late. With kind regards, Jan [1] https://github.com/aamelnikov/draft-rfc4551-bis/pull/1 --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From lear@cisco.com Tue Jan 7 09:00:40 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA41AE02E for ; Tue, 7 Jan 2014 09:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AOEUOwgwWem for ; Tue, 7 Jan 2014 09:00:39 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id EECCB1ADFA0 for ; Tue, 7 Jan 2014 09:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1389114030; x=1390323630; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4gnTym0VpfiZImjFWCeuZb9Y4RB1EhM1I4P6iGzm2xA=; b=daTauamfuBQURJvZiESjZCUA7UFl4P6awkFJWtouTlo5TCzu41axfFdD cbsbfEXHGSrdd3V8YTo2xHRCbGKN68hIenLqnw0jSOUdvDQYQ0bWb1pns Iq7rFynvluurd6pKWcSEXGA3xSbF0AG7bfdyQwIojfNE9xDBc6aSM/PE2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFsyzFKQ/khN/2dsb2JhbABZgws4g1O2aIESFnSCJQEBAQQjDwFFEQsYAgIFFgsCAgkDAgECASsaBgEMCAEBiAANqXSaIhMEgSmNYoJvgUgBA5gXkhWDLjs X-IronPort-AV: E=Sophos;i="4.95,619,1384300800"; d="scan'208";a="2628472" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 07 Jan 2014 17:00:29 +0000 Received: from mctiny.local ([10.61.211.253]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s07H0Sn4017383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 17:00:29 GMT Message-ID: <52CC32AC.6050304@cisco.com> Date: Tue, 07 Jan 2014 18:00:28 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?SmFuIEt1bmRyw6F0?= , imapext@ietf.org References: <20140107114049.19981.81780.idtracker@ietfa.amsl.com> <50cf231f-4bd5-4a40-b2fa-a6dd4ffa5c18@flaska.net> In-Reply-To: <50cf231f-4bd5-4a40-b2fa-a6dd4ffa5c18@flaska.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-07.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:00:40 -0000 I'm sorry, Jan. I've passed the work on to the IESG. Barry can send it back if the group really thinks this is important. Eliot On 1/7/14 4:22 PM, Jan Kundrát wrote: > Hi Alexey, > I have tried to split the VANISHED and VANISHED (EARLIER) into two > separate sections, as discussed in December. Sorry for this rather > long delay. > > The changes live at [1]. If you push the -08 version, I can easily > rebase these changes on top of that. > > Hope it isn't too late. > > With kind regards, > Jan > > [1] https://github.com/aamelnikov/draft-rfc4551-bis/pull/1 > From barryleiba@gmail.com Fri Jan 10 14:38:17 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75FA1AE1BA for ; Fri, 10 Jan 2014 14:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOtNHwQeh8eI for ; Fri, 10 Jan 2014 14:38:14 -0800 (PST) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 582231ACCF2 for ; Fri, 10 Jan 2014 14:38:14 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id w4so2298307qeb.36 for ; Fri, 10 Jan 2014 14:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lxCl0z9V/7jIZRDUlbPCyGcI19Ai1lmVjIxefnYE7d4=; b=JssblmOpJwmCoSHuSrVYlzyEyh9y5H2lwd603OUQdhlbi7Vm1P4l0WpYXmbPU4kms+ axDQSi026scyr37CrHssLKuw2hPI1zC7P5eYq2jnN7YVq966wrWvVUj9E5rDp0eOQypw 4Vs+PKTDOot7Pi/jO1xpZm95hoXNGO+GACfZQOR8cRyCosMTe50pLPv54g0oPw7I6vSj z6TQNxRHHjAYSyT4Rt7ayWPXA6XQJ83fvFHVFIEONMWCGKVZcldpijSFrNVMBjkY+Jsx 9NObbQTTXfDPSQNLtWef6er+Nub3gJBQJ3yx/UX6hnBVOxpyHeJD1q7GWbW5lic8qQlC jppQ== MIME-Version: 1.0 X-Received: by 10.49.59.83 with SMTP id x19mr12409836qeq.47.1389393484055; Fri, 10 Jan 2014 14:38:04 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.17.131 with HTTP; Fri, 10 Jan 2014 14:38:03 -0800 (PST) In-Reply-To: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2014 17:38:03 -0500 X-Google-Sender-Auth: 8jW9Nr05O7fd-QrjzXveyfW4FGQ Message-ID: From: Barry Leiba To: "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:38:17 -0000 On Tue, Jan 7, 2014 at 9:10 AM, Eliot Lear wrote: > Eliot Lear has requested publication of draft-ietf-qresync-rfc5162bis-08 as > Proposed Standard on behalf of the QRESYNC working group. > > Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ And I have completed my AD review of the documentents below. Thanks, all, for the work on this. Barry, Applications AD ----------------------------------------------------------------- -- Section 1 -- As I discussed with Alexey, this document does not actually "update" 3501 or 4315. You should explain the update to 2683 in the Introduction, to make it less easy to miss. I suggest just adding a brief paragraph to the end of Section 1: NEW Also, Section 4 of this document updates the IMAP line length limit recommended in Section 3.2.1.5 of [RFC2683]. END -- Section 2 -- The term "metadata" or "metadata item" is used throughout this document. It refers to any system or user-defined keyword. You need a hyphen after "system", so it's "system- or user-defined". Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not This paragraph repeats what's in RFC 5257, Section 3.3, but does it incompletely. I'd strongly prefer replacing it with a reference to 5257 Section 3.3. See Section 1 for the definition of a "CONDSTORE-aware client" and a "CONDSTORE enabling command". There's nothing like this in Section 1. It looks like you mean 3.1. Understanding of the IMAP message sequence numbers and UIDs and the EXPUNGE response [RFC3501] is essential when reading this document. This is OK as it is, but 3501 is a big spec and these are, as you say, essential. It would help to point the reader more specifically: NEW Understanding of the IMAP message sequence numbers and UIDs (see [RFC3501], Section 2.3.1) and the EXPUNGE response (see [RFC3501], Section 7.4.1) is essential when reading this document. END -- Section 3.1 -- An IMAP server that supports CONDSTORE MUST associate a positive unsigned 63-bit (*) value called a modification sequence (mod- sequence) with every IMAP message. Minor editorial: I think this needs to have "called a modification sequence" set off by commas, for readability. This reflects consensus among WG members, including server implementers. I find this an odd thing to put in the document, and suggest removing it. If you strongly want to keep it, at least change "WG members" to "working group participants". Whenever the state of a flag changes (i.e., the flag is added where previously it wasn't set, or the flag is removed and before it was set) This shows why I think "i.e." and "e.g." should be avoided. I think you want "e.g." here (there are other ways the state of a flag can change). I also think the "and" needs to be removed. The best answer is to re-word this, and not use a Latin abbreviation. While we're at that paragraph, I'd really appreciate it if you'd be consistent in using "set" and either "un-set" or "cleared" to refer to the state of a flag. Having "added", "set", and "present" mean the same thing is simply confusing. The last sentence of the paragraph, for example, would read better as, "Setting a flag that is already set, or clearing a flag that is not set, SHOULD NOT change the mod-sequence." b. adds the MODIFIED response code which should be used with an OK response to the STORE command. (It can also be used in a NO response.) This is a case where I think a lower-case "should" doesn't work well. Either make it "SHOULD be used" or use another word (such as "is used"). f. extends the syntax of untagged SEARCH responses to include mod- sequence. This also applies to ESEARCH, and you should say that here, even though it's specified in 4731. g. adds new OK untagged responses for the SELECT and EXAMINE commands. There are already OK untagged responses. Maybe it'd be better to say which response codes you're adding. h. defines an additional parameter to SELECT/EXAMINE commands. Maybe "defined an additional "xxx" parameter..." ? o an ENABLE command containing "CONDSTORE" as one of the parameters. (This requirement only applies to servers that also implement the ENABLE extension [RFC5161].) Requirement? This list isn't put forth as requirements; it's listing things a client might do. Maybe, "This option only applies when the client is communicating with a server that also implements...." The server MUST include mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed The "subsequent" seems to be dangling. But we can fix that together with something else. I think the last paragraph in the section would work better if we did this: OLD A client supporting CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing: NEW A client supporting CONDSTORE extension indicates its willingness to receive mod-sequence updates in all untagged FETCH responses by issuing one of the following, which are called "CONDSTORE enabling commands": END OLD The server MUST include mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or an external agent. NEW Once a client issues a CONDSTORE enabling command, it has announced itself as a "CONDSTORE-aware client". The server MUST then include mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or an external agent. END ...and remove the first two sentences of the last paragraph in the section. -- Section 3.1.2.2 -- A server that returned NOMODSEQ response code for a mailbox, which subsequently receives one of the following commands while the mailbox is selected: ...[list]... MUST reject any such command with a tagged BAD response. I find that sentence odd, split by the list as it is. I suggest this instead: NEW A server that returned NOMODSEQ response code for a mailbox MUST reject any of the following commands while the mailbox remains selected: ...[list]... END -- Section 3.1.3 -- I find the indentation odd: the third paragraph is also part of the algorithm that starts in the second paragraph, yet the indentation of the paragraph is different. That's confusing. Please find a better way to present that; perhaps something like this: START First paragraph. UNCHANGEDSINCE Second paragraph. Third paragraph. Fourth paragraph. END Unless the server has included an unsolicited FETCH to update client's knowledge about messages that have failed the UNCHANGEDSINCE test, upon receipt of the MODIFIED response code, the client SHOULD try to figure out if the required metadata items have indeed changed by issuing FETCH or NOOP command. The way the commas are placed in this is quite messy, and that makes it very hard to parse correctly. It's not clear, for example, what is dependent upon the receipt of the MODIFIED response code (is it what comes before, or what comes after?). I think it's supposed to be what comes after, and I think this gets the commas right (removed comma after "MODIFIED response code, and added one after "indeed changed"): NEW Unless the server has included an unsolicited FETCH to update client's knowledge about messages that have failed the UNCHANGEDSINCE test, upon receipt of the MODIFIED response code the client SHOULD try to figure out if the required metadata items have indeed changed, by issuing FETCH or NOOP command. END The client SHOULD allow for a configurable but reasonable number of retries (at least 2). SHOULD, really? I think not. I suggest non-2119 advice here. And anyway, is there really a point in having this configurable? What user is going to change (or even hope to understand) such a knob? -- Section 3.1.4.1 -- CHANGEDSINCE CHANGEDSINCE FETCH modifier allows to create a further subset of the list of messages described by sequence set. "Allows to create"? That doesn't work. Allows to create? As specified in Section 1, once the client has specified the MODSEQ message data item in a FETCH request, the server starts including the MODSEQ FETCH response data items in all subsequent unsolicited FETCH responses. Again, I think the reference needs to be to Section 3.1, not Section 1. I think the "Syntax:" lines are confusing, as there's no separation between the syntax and the explanation. I suggest putting them on separate lines. when the server also supports the QRESYNC extension (Section 3.2.3) and a "CONDSTORE enabling command" has been issued Minor editorial: You don't need quoted around that here, once the term has been defined. This is in other places too; please check it. -- Section 3.1.5 -- For a flag , the corresponding has a form " /flags/" as defined in [RFC4466]. Note that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [RFC3501], as the uses syntax for quoted strings. I think the "the" is in the wrong place; this should be "...as uses the syntax for quoted strings (see the examples below)." -- Section 3.1.12 -- Note that the optimization described in this section can't be performed in case of a conditional STORE FLAGS operation. I had to think about this for a minute. You could avoid that by saying, '...in case of a conditional STORE FLAGS operation (without "+" or "-").' -- Section 3.2.1 -- Minor editorial: I don't think this describes "impact to CONDSTORE-only clients". I think it explains why QRESYNC is an improvement. I would change the title to something like "Advantage of QRESYNC over CONDSTORE-only". I would also not say "it is thought likely", but something stronger -- maybe, "it is strongly encouraged that clients that support it also support QRESYNC." -- Section 3.2.3 -- A server compliant with this specification is REQUIRED to support "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE enabling commands", see Section 1), Again, Section 3.1. -- Section 3.2.5 -- This is a long section, and you have two subparts in it. I strongly suggest making "Modification Sequence and UID Parameters:" and "Message sequence match data:" into 3.2.5.1 and 3.2.5.2, respectively. Also, you have some duplicate lines that say "Example:" in this section. For that matter, I note that you have numbered all the other examples. Why is this section different? -- Section 3.2.10 -- The second form doesn't contain the EARLIER tag and is described below. I have to say that some things in this section read a bit convolutedly. I think it's partly because of unnecessary forward references and certain repetition, which combine to make it seem that things are jumping around. There's no need to say that it's described below, and no point in deferring the brief explanation of when it's sent. I suggest this: Leave paragraph 1 ("The VANISHED response reports") as it is. Paragraph 2: NEW The VANISHED response has the same restrictions on when it can be sent as does the EXPUNGE response (see below). Once a client has issued "ENABLE QRESYNC" (and the server has positively responded to that command with the untagged ENABLED response containing QRESYNC), the server MUST use the VANISHED response without the EARLIER tag instead of the EXPUNGE response for all mailboxes that don't return NOMODSEQ when selected. The server continues using VANISHED in lieu of EXPUNGE for the duration of the connection. In particular, this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other connections. END Leave paragraph 3 ("The VANISHED response has two forms.") as it is. Paragraph 4: NEW The second form doesn't contain the EARLIER tag and is sent because of an EXPUNGE or UID EXPUNGE command or because messages were expunged in other connections. The second form decrements the number of messages in the mailbox, and adjusts the message sequence numbers for the messages remaining in the mailbox to account for the expunged messages. Because of this housekeeping, it is not necessary for the server to send an EXISTS response the report the new message count. See the example at the end of this section). END Paragraph 5 is deleted, having been merged above. For paragraph 6: OLD Note that a VANISHED response without the EARLIER tag (i.e. a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections) MUST only refer to a message which was visible to the client in the current session at the time the VANISHED response is sent. NEW A VANISHED response without the EARLIER tag MUST refer only to messages that are visible to the client in the current session at the time the VANISHED response is sent. END (...and leave the rest of the paragraph as it is) This fixes a number of problems with usage, as well as trimming it to make it more readable. Paragraph 7 (this one's a real twister as it is!): OLD Because clients handle the two different forms of the VANISHED response differently, servers MUST NOT report UIDs resulting from a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same VANISHED response as UIDs of messages expunged now (i.e., messages expunged in other connections). Instead, the server MUST send separate VANISHED responses: one with the EARLIER tag and one without. NEW Because clients handle the two different forms of the VANISHED response differently, servers MUST NOT combine them: messages are reported in VANISHED responses with or without the EARLIER tag, as appropriate to the cause, and, if necessary, two VANISHED responses are sent (one with EARLIER and one without). END That's the end of my changes for this issue. If you want to discuss this one with me, that's fine... I want to let you know that I feel very strongly that some changes like this, if not exactly this, be made in this section. I found it very awkward to read. In the example at the end of the section, the difference between "x" and "X" is sufficiently subtle that I suggest using "x" and "D" instead. Also, it would be a *really* good idea to include a first-form VANISHED response in the example... perhaps a case where both first- and second-form VANISHED are sent. It's odd to have the explanation of the two forms here, along with a paragraph about how important the distinction is, to include an example, and not to include that aspect in the example. -- Section 5.1 -- I was very confused by the second paragraph until I realized that the first "the" shouldn't be there. But I recomment this change: OLD Clients that use the message sequence match data can reduce the scope of this VANISHED response substantially in the typical case where expunges have not happened, or happen only toward the end of the mailbox. NEW A client can substantially reduce the size of VANISHED responses by providing the server with message sequence match data (see Section 3.2.5.2). This is especially effective in the typical case where no messages have been expunged, or all expunges were toward the end of the mailbox. END -- Section 5.2 -- The "that is" part really seems weird here, because you wind up saying that a server can omit the VANISHED response when there have been no expunges, which is kind of obvious. I think it works better this way: OLD A server that stores the HIGHESTMODSEQ value at the time of the last EXPUNGE can omit the VANISHED response when a client provides a MODSEQ value that is equal to, or higher than, the current value of this datum, that is, when there have been no EXPUNGEs. NEW A server that stores the HIGHESTMODSEQ value at the time of the last EXPUNGE can omit the VANISHED response when a client provides a MODSEQ value that is equal to, or higher than that HIGHESTMODSEQ value, because there have been no messages expunged during the time period the client is concerned about. END -- Section 5.3 -- One possible way to correctly implement the extension described in this document is to store a queue There are two extensions described in this document. Please just name the extension you mean. And again, I think this helps: OLD Note that if the client provides the message sequence match data, NEW If the client provides the server with message sequence match data, END (What's the value of all the "note that"s, anyway? They're pointless words, most of the time. The "Also, note that" can be removed from the next paragraph as well, with no loss in nuance.) -- Section 6 -- An advanced disconnected mail client SHOULD use the QRESYNC and CONDSTORE extensions when they are supported by the server. It'a a very small point, but the "and" seems funny because QRESYNC *includes* CONDSTORE, according to the first sentence of Secton 3.2. So why not just, "An advanced disconnected mail client SHOULD use the QRESYNC extension when it is supported by the server." ? -- Appendix C -- Did Mark Crispin really provide feedback on this revision of the document? Or would it be better to acknowledge him in a different way? ----------------------------------------------------------------- From alexey.melnikov@isode.com Mon Jan 13 10:14:59 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CB81AE174 for ; Mon, 13 Jan 2014 10:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps46Epj6cqLG for ; Mon, 13 Jan 2014 10:14:54 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC71AE098 for ; Mon, 13 Jan 2014 10:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1389636882; d=isode.com; s=selector; i=@isode.com; bh=n8Qs2BbxE6aNBL4fe20UkKlJSJR52niaelJpNiR1sAE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=AdUDmgd5SS2pP1jFF0S5smH6Txm9sE0/8QP9nNtHEmo+y3f4nBtL6eniGuSjKDYf0wdvwX ehenqcBfPFxe810G3/hE8LteemnlSxx5kaQovUiqs5YF4TibAnZMrGdQD4PePMXK+SyTJI 3LjFmbgIxvDFhbzInMlpcyHMu1XaqqA=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Jan 2014 18:14:42 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52D42D12.6090705@isode.com> Date: Mon, 13 Jan 2014 18:14:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Barry Leiba References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "imapext@ietf.org" , "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:14:59 -0000 On 10/01/2014 22:38, Barry Leiba wrote: > On Tue, Jan 7, 2014 at 9:10 AM, Eliot Lear wrote: >> Eliot Lear has requested publication of draft-ietf-qresync-rfc5162bis-08 as >> Proposed Standard on behalf of the QRESYNC working group. >> >> Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ > And I have completed my AD review of the documentents below. Thanks, > all, for the work on this. Hi Barry, Thank you for detailed review comments and suggestions about how to address them. I am agreeing with most of them. See specific replies below. > Barry, Applications AD > > ----------------------------------------------------------------- > -- Section 1 -- > As I discussed with Alexey, this document does not actually "update" > 3501 or 4315. You should explain the update to 2683 in the > Introduction, to make it less easy to miss. I suggest just adding a > brief paragraph to the end of Section 1: > > NEW > Also, Section 4 of this document updates the IMAP line length limit > recommended in Section 3.2.1.5 of [RFC2683]. > END Added something similar to the Abstract (which already contained related text). > -- Section 2 -- > The term "metadata" or "metadata item" is used throughout this > document. It refers to any system or user-defined keyword. > > You need a hyphen after "system", so it's "system- or user-defined". > > Some IMAP mailboxes are private, accessible only to the owning user. > Other mailboxes are not > > This paragraph repeats what's in RFC 5257, Section 3.3, but does it > incompletely. I'd strongly prefer replacing it with a reference to 5257 > Section 3.3. This is going to be a downref to an Experimental RFC. Is there a need to do that? > See Section 1 for the definition of a "CONDSTORE-aware client" and a > "CONDSTORE enabling command". > > There's nothing like this in Section 1. It looks like you mean 3.1. Fixed. > Understanding of the IMAP message sequence numbers and UIDs and the > EXPUNGE response [RFC3501] is essential when reading this document. > > This is OK as it is, but 3501 is a big spec and these are, as you say, > essential. It would help to point the reader more specifically: > > NEW > Understanding of the IMAP message sequence numbers and UIDs (see > [RFC3501], Section 2.3.1) and the EXPUNGE response (see [RFC3501], > Section 7.4.1) is essential when reading this document. > END Ok. > -- Section 3.1 -- > > An IMAP server that supports CONDSTORE MUST associate a positive > unsigned 63-bit (*) value called a modification sequence (mod- > sequence) with every IMAP message. > > Minor editorial: I think this needs to have "called a modification sequence" > set off by commas, for readability. Good point. > This reflects consensus among WG members, including > server implementers. > > I find this an odd thing to put in the document, and suggest removing it. > If you strongly want to keep it, at least change "WG members" to "working > group participants". This is more for you/IESG. I don't mind deleting it. > Whenever the state of a flag changes (i.e., > the flag is added where previously it wasn't set, or the flag is > removed and before it was set) > > This shows why I think "i.e." and "e.g." should be avoided. I think you > want "e.g." here (there are other ways the state of a flag can change). I don't think so, there are no other ways. > I also think the "and" needs to be removed. The best answer is to re-word > this, and not use a Latin abbreviation. > > While we're at that paragraph, I'd really appreciate it if you'd be > consistent in using "set" and either "un-set" or "cleared" to refer to the > state of a flag. Having "added", "set", and "present" mean the same thing > is simply confusing. The last sentence of the paragraph, for example, would > read better as, "Setting a flag that is already set, or clearing a flag that > is not set, SHOULD NOT change the mod-sequence." Ok. > b. adds the MODIFIED response code which should be used with an OK > response to the STORE command. (It can also be used in a NO > response.) > > This is a case where I think a lower-case "should" doesn't work well. > Either make it "SHOULD be used" or use another word (such as "is used"). Ok. I've used the latter. > f. extends the syntax of untagged SEARCH responses to include mod- > sequence. > > This also applies to ESEARCH, and you should say that here, even though it's > specified in 4731. Ok. > g. adds new OK untagged responses for the SELECT and EXAMINE > commands. > > There are already OK untagged responses. Maybe it'd be better to say which > response codes you're adding. Ok. > h. defines an additional parameter to SELECT/EXAMINE commands. > > Maybe "defined an additional "xxx" parameter..." ? Ok. > o an ENABLE command containing "CONDSTORE" as one of the parameters. > (This requirement only applies to servers that also implement the > ENABLE extension [RFC5161].) > > Requirement? This list isn't put forth as requirements; it's listing things > a client might do. Maybe, "This option only applies when the client is > communicating with a server that also implements...." Ok. > The server MUST include mod-sequence data in all subsequent untagged > FETCH responses (until the connection is closed > > The "subsequent" seems to be dangling. But we can fix that together with > something else. I think the last paragraph in the section would work better > if we did this: > > OLD > A client supporting CONDSTORE extension indicates its willingness to > receive mod-sequence updates in all untagged FETCH responses by > issuing: > NEW > A client supporting CONDSTORE extension indicates its willingness to > receive mod-sequence updates in all untagged FETCH responses by > issuing one of the following, which are called "CONDSTORE enabling > commands": > END > > OLD > The server MUST include mod-sequence data in all subsequent untagged > FETCH responses (until the connection is closed), whether they were > caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or > an external agent. > NEW > Once a client issues a CONDSTORE enabling command, it has announced > itself as a "CONDSTORE-aware client". The server MUST then include > mod-sequence data in all subsequent untagged FETCH responses (until > the connection is closed), whether they were caused by a regular > STORE, a STORE with UNCHANGEDSINCE modifier, or an external agent. > END > > ...and remove the first two sentences of the last paragraph in the section. This works, thanks. > -- Section 3.1.2.2 -- > > A server that returned NOMODSEQ response code for a mailbox, which > subsequently receives one of the following commands while the mailbox > is selected: > ...[list]... > MUST reject any such command with a tagged BAD response. > > I find that sentence odd, split by the list as it is. I suggest this > instead: > > NEW > A server that returned NOMODSEQ response code for a mailbox MUST > reject any of the following commands while the mailbox remains > selected: > ...[list]... Used a slightly changed version of your text, as you dropped mentioning of BAD, which is important. > END > > -- Section 3.1.3 -- > I find the indentation odd: the third paragraph is also part of the > algorithm that starts in the second paragraph, yet the indentation of the > paragraph is different. That's confusing. Please find a better way to > present that; perhaps something like this: > > START > First paragraph. > UNCHANGEDSINCE > Second paragraph. > > Third paragraph. > Fourth paragraph. > END I haven't done this yet, but I will have a look. > Unless the server has included an unsolicited FETCH to update > client's knowledge about messages that have failed the UNCHANGEDSINCE > test, upon receipt of the MODIFIED response code, the client SHOULD > try to figure out if the required metadata items have indeed changed > by issuing FETCH or NOOP command. > > The way the commas are placed in this is quite messy, and that makes it very > hard to parse correctly. It's not clear, for example, what is dependent > upon the receipt of the MODIFIED response code (is it what comes before, or > what comes after?). I think it's supposed to be what comes after, and I > think this gets the commas right (removed comma after "MODIFIED response > code, and added one after "indeed changed"): > > NEW > Unless the server has included an unsolicited FETCH to update > client's knowledge about messages that have failed the UNCHANGEDSINCE > test, upon receipt of the MODIFIED response code the client SHOULD > try to figure out if the required metadata items have indeed changed, > by issuing FETCH or NOOP command. > END Yes. > The client SHOULD allow > for a configurable but reasonable number of retries (at least 2). > > SHOULD, really? I think not. I suggest non-2119 advice here. And anyway, > is there really a point in having this configurable? What user is going to > change (or even hope to understand) such a knob? Oh, good point. This was not supposed to be a user visible option, more like an IMAP library option. > -- Section 3.1.4.1 -- > > CHANGEDSINCE CHANGEDSINCE FETCH modifier allows to > create a further subset of the list of messages described by > sequence set. Should be "allows to further subset the list ...". > "Allows to create"? That doesn't work. Allows to create? > As specified in Section 1, once the client has specified the MODSEQ > message data item in a FETCH request, the server starts including the > MODSEQ FETCH response data items in all subsequent unsolicited FETCH > responses. > > Again, I think the reference needs to be to Section 3.1, not Section 1. Yes. > I think the "Syntax:" lines are confusing, as there's no separation between > the syntax and the explanation. I suggest putting them on separate lines. Ok. > when the server also supports the QRESYNC extension (Section 3.2.3) > and a "CONDSTORE enabling command" has been issued > > Minor editorial: You don't need quoted around that here, once the term has > been defined. This is in other places too; please check it. Ok. > -- Section 3.1.5 -- > > For a flag , the corresponding has a form " > /flags/" as defined in [RFC4466]. Note that the leading > "\" character that denotes a system flag has to be escaped as per > Section 4.3 of [RFC3501], as the uses syntax for > quoted strings. > > I think the "the" is in the wrong place; this should be "...as > uses the syntax for quoted strings (see the examples below)." Right. > -- Section 3.1.12 -- > > Note that the optimization described in this section can't be > performed in case of a conditional STORE FLAGS operation. > > I had to think about this for a minute. You could avoid that by saying, > '...in case of a conditional STORE FLAGS operation (without "+" or "-").' Ok. > -- Section 3.2.1 -- > Minor editorial: I don't think this describes "impact to CONDSTORE-only > clients". I think it explains why QRESYNC is an improvement. It is a bit different: it is explaining that CONDSTORE-only clients can trigger non optimal response from QRESYNC servers. > I would > change the title to something like "Advantage of QRESYNC over > CONDSTORE-only". > > I would also not say "it is thought likely", but something stronger -- > maybe, "it is strongly encouraged that clients that support it also support > QRESYNC." Ok. > -- Section 3.2.3 -- > > A server > compliant with this specification is REQUIRED to support "ENABLE > QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE > enabling commands", see Section 1), > > Again, Section 3.1. Right. > -- Section 3.2.5 -- > This is a long section, and you have two subparts in it. I strongly suggest > making "Modification Sequence and UID Parameters:" and "Message sequence > match data:" into 3.2.5.1 and 3.2.5.2, respectively. Ok. > Also, you have some duplicate lines that say "Example:" in this section. > For that matter, I note that you have numbered all the other examples. Why > is this section different? No particular reason, I will have a more detailed look at this. > -- Section 3.2.10 -- > > The second form doesn't contain the EARLIER tag and is described > below. > > I have to say that some things in this section read a bit convolutedly. I > think it's partly because of unnecessary forward references and certain > repetition, which combine to make it seem that things are jumping around. > There's no need to say that it's described below, and no point in deferring > the brief explanation of when it's sent. I suggest this: > > Leave paragraph 1 ("The VANISHED response reports") as it is. > > Paragraph 2: > NEW > The VANISHED response has the same restrictions on when it can be > sent as does the EXPUNGE response (see below). Once a client has > issued "ENABLE QRESYNC" (and the server has positively responded > to that command with the untagged ENABLED response containing > QRESYNC), the server MUST use the VANISHED response without the > EARLIER tag instead of the EXPUNGE response for all mailboxes that > don't return NOMODSEQ when selected. The server continues using > VANISHED in lieu of EXPUNGE for the duration of the connection. > In particular, this affects the EXPUNGE [RFC3501] and UID EXPUNGE > [UIDPLUS] commands, as well as messages expunged in other > connections. > END > > Leave paragraph 3 ("The VANISHED response has two forms.") as it is. > > Paragraph 4: > NEW > The second form doesn't contain the EARLIER tag and is sent > because of an EXPUNGE or UID EXPUNGE command or because messages > were expunged in other connections. The second form decrements > the number of messages in the mailbox, and adjusts the message > sequence numbers for the messages remaining in the mailbox to > account for the expunged messages. Because of this housekeeping, > it is not necessary for the server to send an EXISTS response > the report the new message count. See the example at the end of > this section). > END > > Paragraph 5 is deleted, having been merged above. > > For paragraph 6: > OLD > Note that a VANISHED response without the EARLIER tag (i.e. a > VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages > expunged in other connections) MUST only refer to a message which was > visible to the client in the current session at the time the VANISHED > response is sent. > NEW > A VANISHED response without the EARLIER tag MUST refer only to > messages that are visible to the client in the current session > at the time the VANISHED response is sent. > END > > (...and leave the rest of the paragraph as it is) This fixes a number of > problems with usage, as well as trimming it to make it more readable. > > Paragraph 7 (this one's a real twister as it is!): > OLD > Because clients handle the two different forms of the VANISHED > response differently, servers MUST NOT report UIDs resulting from a > UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same > VANISHED response as UIDs of messages expunged now (i.e., messages > expunged in other connections). Instead, the server MUST send > separate VANISHED responses: one with the EARLIER tag and one > without. > NEW > Because clients handle the two different forms of the VANISHED > response differently, servers MUST NOT combine them: messages > are reported in VANISHED responses with or without the EARLIER > tag, as appropriate to the cause, and, if necessary, two > VANISHED responses are sent (one with EARLIER and one without). > END Used all of your suggestions, thanks. > That's the end of my changes for this issue. If you want to discuss this > one with me, that's fine... I want to let you know that I feel very strongly > that some changes like this, if not exactly this, be made in this section. > I found it very awkward to read. > > In the example at the end of the section, the difference between "x" and "X" > is sufficiently subtle that I suggest using "x" and "D" instead. Ok. > Also, it > would be a *really* good idea to include a first-form VANISHED response in > the example... perhaps a case where both first- and second-form VANISHED > are sent. It's odd to have the explanation of the two forms here, along > with a paragraph about how important the distinction is, to include an > example, and not to include that aspect in the example. I haven't done that yet, but look at the latest version (which I will post shortly). > -- Section 5.1 -- > I was very confused by the second paragraph until I realized that the first > "the" shouldn't be there. But I recomment this change: > > OLD > Clients that use the message sequence match data can reduce the scope > of this VANISHED response substantially in the typical case where > expunges have not happened, or happen only toward the end of the > mailbox. > NEW > A client can substantially reduce the size of VANISHED responses by > providing the server with message sequence match data (see Section > 3.2.5.2). This is especially effective in the typical case where no > messages have been expunged, or all expunges were toward the end of the > mailbox. > END Ok. > -- Section 5.2 -- > The "that is" part really seems weird here, because you wind up saying that > a server can omit the VANISHED response when there have been no expunges, > which is kind of obvious. I think it works better this way: > > OLD > A server that stores the HIGHESTMODSEQ value at the time of the last > EXPUNGE can omit the VANISHED response when a client provides a > MODSEQ value that is equal to, or higher than, the current value of > this datum, that is, when there have been no EXPUNGEs. > NEW > A server that stores the HIGHESTMODSEQ value at the time of the last > EXPUNGE can omit the VANISHED response when a client provides a > MODSEQ value that is equal to, or higher than that HIGHESTMODSEQ > value, because there have been no messages expunged during the time > period the client is concerned about. > END Ok. > -- Section 5.3 -- > > One possible way to correctly implement the extension described in > this document is to store a queue > > There are two extensions described in this document. Please just name the > extension you mean. Good point. This text was there before the merge. > And again, I think this helps: > > OLD > Note that if the client provides the message sequence match data, > NEW > If the client provides the server with message sequence match data, > END > > (What's the value of all the "note that"s, anyway? They're pointless > words, most of the time. The "Also, note that" can be removed from the next > paragraph as well, with no loss in nuance.) Changed. > -- Section 6 -- > > An advanced disconnected mail client SHOULD use the QRESYNC and > CONDSTORE extensions when they are supported by the server. > > It'a a very small point, but the "and" seems funny because QRESYNC > *includes* CONDSTORE, according to the first sentence of Secton 3.2. So why > not just, "An advanced disconnected mail client SHOULD use the QRESYNC > extension when it is supported by the server." ? This is trying to say "use QRESYNC if you can, but even if you can't, use CONDSTORE". > -- Appendix C -- > Did Mark Crispin really provide feedback on this revision of the document? > Or would it be better to acknowledge him in a different way? I will discuss this off-list. Best Regards, Alexey From internet-drafts@ietf.org Mon Jan 13 10:35:01 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C61ADF96; Mon, 13 Jan 2014 10:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxveMQ681G_j; Mon, 13 Jan 2014 10:34:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C21ADF93; Mon, 13 Jan 2014 10:34:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113183459.28964.22057.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 10:34:59 -0800 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-09.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:35:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extensions for Conditional STORE Operation o= r Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resync= hronization (QRESYNC) Authors : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-09.txt Pages : 50 Date : 2014-01-13 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, this document also updates the line length recommendation in Section 3.2.1.5 of RFC 2683. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Mon Jan 13 10:40:22 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03CF1ADFB5 for ; Mon, 13 Jan 2014 10:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYyooeuGyccq for ; Mon, 13 Jan 2014 10:40:20 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id AFE7A1ADF93 for ; Mon, 13 Jan 2014 10:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1389638409; d=isode.com; s=selector; i=@isode.com; bh=fx2JyuW4hGt59eBGfeGM/1pwaxQjz9CoILJO21EmGH8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Vi6X0PDoxIYfkWSOVpKHNFF0B3t6hgNBm6bqD6E3rbLUYnUgE8vKx8GYIMQHc8wUWUqsS7 ck6CPoJ2DsNTy/xpsgLJjJZi449wbBSGbzDOhPAkG9pCqsPURLiyubl9wDoVu69hFsUBJE aKsuGgb5zstVPrzDevCTS2fjStW+Lv8=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Jan 2014 18:40:09 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52D43308.6070307@isode.com> Date: Mon, 13 Jan 2014 18:40:08 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: imapext@ietf.org References: <20140113183459.28964.22057.idtracker@ietfa.amsl.com> In-Reply-To: <20140113183459.28964.22057.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-09.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:40:23 -0000 On 13/01/2014 18:34, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-09 This version incorporates Jan's suggestions and 98% of Barry's comments. From barryleiba@gmail.com Mon Jan 13 14:15:42 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601811ADF47 for ; Mon, 13 Jan 2014 14:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB9IxfdmvrnA for ; Mon, 13 Jan 2014 14:15:40 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1457B1ADA5D for ; Mon, 13 Jan 2014 14:15:39 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so2729774qaq.6 for ; Mon, 13 Jan 2014 14:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8OWxtNzsfsTn3AM98V9QIMRkneMB3Nt3LB7dFvpsQ08=; b=jYKzSU2lA3uObZ6pJB0cOFyugcQ2DCN3Lx+mfDhEYOVw6ov8+/i++uvPS1IlD9vn20 WV3tgnGZasaOeh2KAiPoshTm+5MKoa6hoxWLYNkOYUEF5FGeAV0+TxXnOhZX3Rn1cbgk mUkCuDOt3mzZCvHTHmwl2pt5SmPvgJB9QoQoKFCr2cyVQhXwlKnQqEQFGJeJKRfwj3+e /hB/L/46kT7HgIPk0LbXoOBpK6w/pUGjvCsIYFCx2FA0s9oe911uYtm1N1mmqrnKYc03 69EKXmkFFgylfBzuwtUBVVzdIy+bipfmH+t73cYb2ak5C1Ce9cuiIDpY0KhSK/pBF5B8 GUuQ== MIME-Version: 1.0 X-Received: by 10.224.115.137 with SMTP id i9mr43947688qaq.37.1389651328528; Mon, 13 Jan 2014 14:15:28 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.23.67 with HTTP; Mon, 13 Jan 2014 14:15:28 -0800 (PST) In-Reply-To: <52D42D12.6090705@isode.com> References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> <52D42D12.6090705@isode.com> Date: Mon, 13 Jan 2014 17:15:28 -0500 X-Google-Sender-Auth: RJI9LxuAm8g6vdmy0uCqbVHpY3Y Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" , "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:15:42 -0000 Thanks for the quick action! Leaving just things that need more discussion: >> Some IMAP mailboxes are private, accessible only to the owning user. >> Other mailboxes are not >> >> This paragraph repeats what's in RFC 5257, Section 3.3, but does it >> incompletely. I'd strongly prefer replacing it with a reference to 5257 >> Section 3.3. > > This is going to be a downref to an Experimental RFC. Is there a need to do > that? Now that we're allowing downrefs, it's not a bad thing. But it's fair if you'd prefer to have this include all of the related stuff from 5257, and have it be the proper reference for it now. If you do that, please make sure what you bring over here is complete. >> This reflects consensus among WG members, including >> server implementers. >> >> I find this an odd thing to put in the document, and suggest removing it. >> If you strongly want to keep it, at least change "WG members" to "working >> group participants". > > This is more for you/IESG. I don't mind deleting it. Right... notes to the IESG can either be put into the shepherd writeup, or labelled as "IESG note [RFC Editor please remove]:" in the draft. >> -- Section 3.1.4.1 -- >> >> CHANGEDSINCE CHANGEDSINCE FETCH modifier allows to >> create a further subset of the list of messages described by >> sequence set. > > Should be "allows to further subset the list ...". > >> "Allows to create"? That doesn't work. Allows to create? Well, but that still has the "allows' problem, and also turns "subset" into a verb. I don't care about the verbing so much -- do as you like there -- but "allows" has to have a direct object, which is missing in the "allows to create" or "allows to subset" construction. You have to say *who* (or what) is allowed to do that. You can say, "allows the client to subset" or "allows the server to subset", or even "allows Barry's mother to subset", but you can't just say "allows to subset". >> Also, it >> would be a *really* good idea to include a first-form VANISHED response in >> the example... perhaps a case where both first- and second-form VANISHED >> are sent. It's odd to have the explanation of the two forms here, along >> with a paragraph about how important the distinction is, to include an >> example, and not to include that aspect in the example. > > I haven't done that yet, but look at the latest version (which I will post > shortly). I had a quick look. Yes, I think it still could use an example with (EARLIER). But that's not something we need to delay last call for. >> -- Section 6 -- >> >> An advanced disconnected mail client SHOULD use the QRESYNC and >> CONDSTORE extensions when they are supported by the server. >> >> It'a a very small point, but the "and" seems funny because QRESYNC >> *includes* CONDSTORE, according to the first sentence of Secton 3.2. So >> why >> not just, "An advanced disconnected mail client SHOULD use the QRESYNC >> extension when it is supported by the server." ? > > This is trying to say "use QRESYNC if you can, but even if you can't, use > CONDSTORE". Ah, OK. That's a little odd, because the whole section assumes the presence of QRESYNC in its advice. But perhaps this could worded to include what you say above; maybe this?: NEW An advanced disconnected mail client SHOULD use the QRESYNC extension when it is supported by the server, and should use CONDSTORE if it is supported and QRESYNC is not. END Barry From iesg-secretary@ietf.org Mon Jan 13 14:34:35 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB681AE107; Mon, 13 Jan 2014 14:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbWVosbSQqd4; Mon, 13 Jan 2014 14:34:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA011A1F1B; Mon, 13 Jan 2014 14:34:34 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140113223433.25406.97543.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 14:34:33 -0800 Cc: imapext@ietf.org Subject: [imapext] Last Call: (IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)) to Proposed Standard X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:34:35 -0000 The IESG has received a request from the IMAP QRESYNC Extension WG (qresync) to consider the following document: - 'IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, The Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional Store extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round-trips. Hence this memo obsoletes RFC 5162. Finally, this document also updates the line length recommendation in Section 3.2.1.5 of RFC 2683. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ballot/ No IPR declarations have been submitted directly on this I-D. From alexey.melnikov@isode.com Thu Jan 16 01:49:29 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3652B1AE1F5 for ; Thu, 16 Jan 2014 01:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vWIWmI_ncra for ; Thu, 16 Jan 2014 01:49:27 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 08F321AE0A5 for ; Thu, 16 Jan 2014 01:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1389865753; d=isode.com; s=selector; i=@isode.com; bh=NkgNba13cMoJ2DwacxzEufbYNuNNyzsZvSOZ0FGOPO4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Uhk/U/Hj/XIfkgjsM7omhqEL6pPXZS2mm6GR2ZvzsIPEi+PRN4e0GkfjLY6auourc2oQ9z uuve7iR9Utsdyp/6ap35PFRp4etq1Q1TCrVdQUhhvnvXLhzJEx1jQTGbyJsTQzidFHloE7 qwIvzJ8l1iFcpoDcwXi3L+AboKi8zkg=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 16 Jan 2014 09:49:13 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52D7AB1A.7010006@isode.com> Date: Thu, 16 Jan 2014 09:49:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Barry Leiba References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000000070802000304030806" Cc: "imapext@ietf.org" , "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 09:49:29 -0000 This is a multi-part message in MIME format. --------------000000070802000304030806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Barry, On 10/01/2014 22:38, Barry Leiba wrote: > -- Section 2 -- > The term "metadata" or "metadata item" is used throughout this > document. It refers to any system- or user-defined keyword. > > Some IMAP mailboxes are private, accessible only to the owning user. > Other mailboxes are not > > This paragraph repeats what's in RFC 5257, Section 3.3, but does it > incompletely. I'd strongly prefer replacing it with a reference to 5257 > Section 3.3. Coming back to this issue. The draft currently says: Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an Access Control List [RFC4314] that permits access by other users, or because it is a shared mailbox. Let's call a metadata item "shared" for the mailbox if any changes to the metadata items are persistent and visible to all other users accessing the mailbox. Otherwise, the metadata item is called "private". Note that private metadata items are still visible to all sessions accessing the mailbox as the same user. Also note that different mailboxes may have different metadata items as shared. RFC 5257 says: Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an ACL [RFC4314 ] that permits access by other users, or because it is a shared mailbox. This raises the issue of shared versus private annotations. If all annotations are private, it is then impossible to have annotations in a shared or otherwise non-private mailbox be visible to other users. This eliminates what could be a useful aspect of annotations in a shared environment. An example of such use is a shared IMAP folder containing bug reports. Engineers may want to use annotations to add information to existing messages, indicate assignments, status, etc. This use requires shared annotations. If all annotations are shared, it is impossible to use annotations for private notes on messages in shared mailboxes. Also, modifying an ACL to permit access to a mailbox by other users may unintentionally expose private information. I do actually like my version better, because it doesn't try to motivate existence of shared versa private metadata. Can you please point out specific changes (or text missing) to my version? Thank you, Alexey --------------000000070802000304030806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Barry,

On 10/01/2014 22:38, Barry Leiba wrote:

-- Section 2 --
   The term "metadata" or "metadata item" is used throughout this
   document.  It refers to any system- or user-defined keyword.

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not

This paragraph repeats what's in RFC 5257, Section 3.3, but does it
incompletely.  I'd strongly prefer replacing it with a reference to 5257
Section 3.3.

Coming back to this issue. The draft currently says:

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not, either because the owner has set an Access
   Control List [RFC4314] that permits access by other users, or because
   it is a shared mailbox.  Let's call a metadata item "shared" for the
   mailbox if any changes to the metadata items are persistent and
   visible to all other users accessing the mailbox.  Otherwise, the
   metadata item is called "private".  Note that private metadata items
   are still visible to all sessions accessing the mailbox as the same
   user.  Also note that different mailboxes may have different metadata
   items as shared.

RFC 5257 says:

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not, either because the owner has set an ACL
   [RFC4314] that permits access by other users, or because it is a
   shared mailbox.

   This raises the issue of shared versus private annotations.

   If all annotations are private, it is then impossible to have
   annotations in a shared or otherwise non-private mailbox be visible
   to other users.  This eliminates what could be a useful aspect of
   annotations in a shared environment.  An example of such use is a
   shared IMAP folder containing bug reports.  Engineers may want to use
   annotations to add information to existing messages, indicate
   assignments, status, etc.  This use requires shared annotations.

   If all annotations are shared, it is impossible to use annotations
   for private notes on messages in shared mailboxes.  Also, modifying
   an ACL to permit access to a mailbox by other users may
   unintentionally expose private information.

I do actually like my version better, because it doesn't try to motivate existence of shared versa private metadata. Can you please point out specific changes (or text missing) to my version?

Thank you,
Alexey

--------------000000070802000304030806-- From brong@fastmail.fm Thu Jan 16 02:12:12 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499401AE2FE for ; Thu, 16 Jan 2014 02:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo5feLW2oHMP for ; Thu, 16 Jan 2014 02:12:09 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0231AE058 for ; Thu, 16 Jan 2014 02:12:09 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A33C220318 for ; Thu, 16 Jan 2014 05:11:54 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Thu, 16 Jan 2014 05:11:54 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= GmagqYuYTuGiusuWrxWJLJ2S0UU=; b=kYPeoMlbQDz6CSAIu4CZKfy3daNlLV7F 7vKXbhC0V8ivGvUNnEXI3wJEsVT9L2uy83Rnl5xU0oDcPwNIg0T68KbSANrzV2C5 ElFDoAvxUMR39QzANP/yHr096NuBTvR+u3+VA5JA52/bvsaZCqeeDO6zA+09lCXH rTLHBQR3TQA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=GmagqYuYTuGiusuWrxWJLJ2S0UU=; b=HZA pDHzCe7iK2ULXU8FpTKTa67DV0rKEwG9t/dXVwYOrYThB+qWiuX/e5TmeAuu+lON Qd6w3DWYFLWoWnkwaMzY00p84gakNOqJstpY+0BKLu/wbts/nKH5/Zff0cxZNzSq TBiWwfDwpNSmpGSMv+SOKSCPKj2837E9aGqdLQKI= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 5C684F00016; Thu, 16 Jan 2014 05:11:54 -0500 (EST) Message-Id: <1389867114.26753.71466085.54CB56F7@webmail.messagingengine.com> X-Sasl-Enc: 67Jds0LqGPTWFHKvFpDMvMlRHPhKIBjqZSYI4UYThd94 1389867114 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1389867114267531"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fdd84f42 In-Reply-To: <52D7AB1A.7010006@isode.com> References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> <52D7AB1A.7010006@isode.com> Date: Thu, 16 Jan 2014 21:11:54 +1100 Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 10:12:12 -0000 This is a multi-part message in MIME format. --_----------=_1389867114267531 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, Jan 16, 2014, at 08:49 PM, Alexey Melnikov wrote: Hi Barry, On 10/01/2014 22:38, Barry Leiba wrote: -- Section 2 -- The term "metadata" or "metadata item" is used throughout this document. It refers to any system- or user-defined keyword. Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not This paragraph repeats what's in RFC 5257, Section 3.3, but does it incompletely. I'd strongly prefer replacing it with a reference to 5257 Section 3.3. Coming back to this issue. The draft currently says: Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an Access Control List [RFC4314] that permits access by other users, or because it is a shared mailbox. Let's call a metadata item "shared" for the mailbox if any changes to the metadata items are persistent and visible to all other users accessing the mailbox. Otherwise, the metadata item is called "private". Note that private metadata items are still visible to all sessions accessing the mailbox as the same user. Also note that different mailboxes may have different metadata items as shared. RFC 5257 says: Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an ACL [[1]RFC4314] that permits access by other users, or because it is a shared mailbox. This raises the issue of shared versus private annotations. If all annotations are private, it is then impossible to have annotations in a shared or otherwise non-private mailbox be visible to other users. This eliminates what could be a useful aspect of annotations in a shared environment. An example of such use is a shared IMAP folder containing bug reports. Engineers may want to use annotations to add information to existing messages, indicate assignments, status, etc. This use requires shared annotations. If all annotations are shared, it is impossible to use annotations for private notes on messages in shared mailboxes. Also, modifying an ACL to permit access to a mailbox by other users may unintentionally expose private information. I do actually like my version better, because it doesn't try to motivate existence of shared versa private metadata. Can you please point out specific changes (or text missing) to my version? Thank you, Alexey The new Cyrus CalDAV/CardDAV support uses annotations to store properties on collection (i.e. name or color on a calendar). We have exactly this issue - we'd like a shared calendar to keep its name and color on sharing, but allow the other user to change the display name and color to their own preferences. Some kind of layered thing. Our current plan is to patch Cyrus to display the shared annotation if set, or the private annotations otherwise. And for the 'owner' to set the shared annotation, and others to set the private annotation. Bron. -- Bron Gondwana brong@fastmail.fm References 1. http://tools.ietf.org/html/rfc4314 --_----------=_1389867114267531 Content-Transfer-Encoding: 7bit Content-Type: text/html

On Thu, Jan 16, 2014, at 08:49 PM, Alexey Melnikov wrote:

Hi Barry,

On 10/01/2014 22:38, Barry Leiba wrote:

-- Section 2 --
   The term "metadata" or "metadata item" is used throughout this
   document.  It refers to any system- or user-defined keyword.

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not

This paragraph repeats what's in RFC 5257, Section 3.3, but does it
incompletely.  I'd strongly prefer replacing it with a reference to 5257
Section 3.3.

Coming back to this issue. The draft currently says:

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not, either because the owner has set an Access
   Control List [RFC4314] that permits access by other users, or because
   it is a shared mailbox.  Let's call a metadata item "shared" for the
   mailbox if any changes to the metadata items are persistent and
   visible to all other users accessing the mailbox.  Otherwise, the
   metadata item is called "private".  Note that private metadata items
   are still visible to all sessions accessing the mailbox as the same
   user.  Also note that different mailboxes may have different metadata
   items as shared.

RFC 5257 says:

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not, either because the owner has set an ACL
   [RFC4314] that permits access by other users, or because it is a
   shared mailbox.

   This raises the issue of shared versus private annotations.

   If all annotations are private, it is then impossible to have
   annotations in a shared or otherwise non-private mailbox be visible
   to other users.  This eliminates what could be a useful aspect of
   annotations in a shared environment.  An example of such use is a
   shared IMAP folder containing bug reports.  Engineers may want to use
   annotations to add information to existing messages, indicate
   assignments, status, etc.  This use requires shared annotations.

   If all annotations are shared, it is impossible to use annotations
   for private notes on messages in shared mailboxes.  Also, modifying
   an ACL to permit access to a mailbox by other users may
   unintentionally expose private information.

I do actually like my version better, because it doesn't try to motivate existence of shared versa private metadata. Can you please point out specific changes (or text missing) to my version?

Thank you,

Alexey

The new Cyrus CalDAV/CardDAV support uses annotations to store properties on collection (i.e. name or color on a calendar). We have exactly this issue - we'd like a shared calendar to keep its name and color on sharing, but allow the other user to change the display name and color to their own preferences. Some kind of layered thing.

Our current plan is to patch Cyrus to display the shared annotation if set, or the private annotations otherwise. And for the 'owner' to set the shared annotation, and others to set the private annotation.

Bron.

Bron Gondwana

brong@fastmail.fm

--_----------=_1389867114267531-- From alexey.melnikov@isode.com Mon Jan 20 06:53:48 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7167E1A0191 for ; Mon, 20 Jan 2014 06:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3a5BmhOAZnI for ; Mon, 20 Jan 2014 06:53:46 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A8EC71A0173 for ; Mon, 20 Jan 2014 06:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1390229625; d=isode.com; s=selector; i=@isode.com; bh=U9Cmy8CksmitvnZGKvp/Wof14CpCq/GdD6Uc7YO7pQU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aUAq71Zb8wzlDrZx30JDMN8XnwORPRYgX+pxNsSF8UjIuJurAY3ND3I9lyC5yF/MdZibbV e/ftG8QSRBDgZJzaNjQKiS38DWvqb0PuM/eQHlQkqgLDtawJLlMST8eZZwc4jxwIuGLoqO VCpC2n4znxtqTVaFLBreTUv3ZsiwaJg=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 20 Jan 2014 14:53:45 +0000 Message-ID: <52DD3871.4020202@isode.com> Date: Mon, 20 Jan 2014 14:53:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Barry Leiba References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> <52D42D12.6090705@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "imapext@ietf.org" , "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 14:53:48 -0000 On 13/01/2014 22:15, Barry Leiba wrote: > Thanks for the quick action! > > Leaving just things that need more discussion: [...] >>> -- Section 3.1.4.1 -- >>> >>> CHANGEDSINCE CHANGEDSINCE FETCH modifier allows to >>> create a further subset of the list of messages described by >>> sequence set. >> Should be "allows to further subset the list ...". >> >>> "Allows to create"? That doesn't work. Allows to create? > Well, but that still has the "allows' problem, and also turns "subset" > into a verb. I don't care about the verbing so much -- do as you like > there -- but "allows" has to have a direct object, which is missing in > the "allows to create" or "allows to subset" construction. You have > to say *who* (or what) is allowed to do that. You can say, "allows > the client to subset" or "allows the server to subset", or even > "allows Barry's mother to subset", but you can't just say "allows to > subset". Ok :-). >>> -- Section 6 -- >>> >>> An advanced disconnected mail client SHOULD use the QRESYNC and >>> CONDSTORE extensions when they are supported by the server. >>> >>> It'a a very small point, but the "and" seems funny because QRESYNC >>> *includes* CONDSTORE, according to the first sentence of Secton 3.2. So >>> why >>> not just, "An advanced disconnected mail client SHOULD use the QRESYNC >>> extension when it is supported by the server." ? >> This is trying to say "use QRESYNC if you can, but even if you can't, use >> CONDSTORE". > Ah, OK. That's a little odd, because the whole section assumes the > presence of QRESYNC in its advice. But perhaps this could worded to > include what you say above; maybe this?: > > NEW > An advanced disconnected mail client SHOULD use the QRESYNC > extension when it is supported by the server, and should use CONDSTORE > if it is supported and QRESYNC is not. > END Ok. From barryleiba.mailing.lists@gmail.com Mon Jan 20 10:34:08 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA46F1A0232 for ; Mon, 20 Jan 2014 10:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EUGvT68jta5 for ; Mon, 20 Jan 2014 10:34:08 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C7B371A01C1 for ; Mon, 20 Jan 2014 10:34:07 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ld13so3056049vcb.32 for ; Mon, 20 Jan 2014 10:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OibJTNvN3aGfG6xby1IdxBPvZLEdJbMixBerXIKMtrk=; b=LxVH3L16Og/Nv8Q8A1UK0j4Kyk7GRFBsvGTcSOiTn2gTMsGQiTB9VMdgsZwsJdzYAJ o43w3AdS9uG0rsidIcpdV+VMjGTlwvJ9/S2oguvVXxK2kW48saCL5oR1V0khMVbxN021 NfJ4XqobJdpovkH/Iam+lYUQjw49wWxq4Ata/+Dos+3baT8hAVOLqeVJP+PDVr7iVhV0 slG0Z2YdqiB5K38xeIXvsxSvN/n3tHW6FHHZnbHs5tPTVZvF28IS3p/sbR5oBtUDKYdX JcMXr+8KBZ4brFfVCTmfUq2jMm+bH04O9ayGXD4FaOZBGkMvP3VXe2TocLvM89XvmD9s cFMQ== MIME-Version: 1.0 X-Received: by 10.52.117.115 with SMTP id kd19mr9438629vdb.15.1390242847842; Mon, 20 Jan 2014 10:34:07 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Mon, 20 Jan 2014 10:34:07 -0800 (PST) In-Reply-To: <52D7AB1A.7010006@isode.com> References: <20140107141049.29034.12683.idtracker@ietfa.amsl.com> <52D7AB1A.7010006@isode.com> Date: Mon, 20 Jan 2014 13:34:07 -0500 X-Google-Sender-Auth: 4xvhU_l_UB4VAUvz4nbw0BEjf4g Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" , "draft-ietf-qresync-rfc5162bis@tools.ietf.org" Subject: Re: [imapext] Publication has been requested for draft-ietf-qresync-rfc5162bis-08 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:34:09 -0000 > This paragraph repeats what's in RFC 5257, Section 3.3, but does it > incompletely. I'd strongly prefer replacing it with a reference to 5257 > Section 3.3. > > Coming back to this issue. The draft currently says: ...strike my comment, and let's just leave the text in the draft as it is. Barry From iana-shared@icann.org Wed Jan 22 10:43:59 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531611A0158; Wed, 22 Jan 2014 10:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eD-gX-sq8Gu; Wed, 22 Jan 2014 10:43:57 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) by ietfa.amsl.com (Postfix) with ESMTP id DFD501A011C; Wed, 22 Jan 2014 10:43:57 -0800 (PST) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s0MIhvZu009376; Wed, 22 Jan 2014 18:43:57 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 506ED56066E; Wed, 22 Jan 2014 18:43:57 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20140113223434.25406.20845.idtracker@ietfa.amsl.com> References: <20140113223434.25406.20845.idtracker@ietfa.amsl.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #738605 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 22 Jan 2014 18:43:57 +0000 X-Mailman-Approved-At: Wed, 22 Jan 2014 18:48:38 -0800 Cc: qresync-chairs@tools.ietf.org, iesg@ietf.org, imapext@ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org Subject: [imapext] [IANA #738605] Last Call: (IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)) to X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 18:43:59 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-qresync-rfc5162bis-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IMAP Capabilities Registry located at: http://www.iana.org/assignments/imap4-capabilities the reference for the capabilities CONDSTORE and QRESYNC will be updated to point to [ RFC-to-be ]. IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN/IANA (END IANA LAST CALL COMMENTS) On Mon Jan 13 14:34:48 2014, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the IMAP QRESYNC Extension WG > (qresync) to consider the following document: > - 'IMAP Extensions for Conditional STORE Operation or Quick Flag Changes > Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization > (QRESYNC)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-01-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Often, multiple IMAP (RFC 3501) clients need to coordinate changes to > a common IMAP mailbox. Examples include different clients working on > behalf of the same user, and multiple users accessing shared > mailboxes. These clients need a mechanism to efficiently synchronize > state changes for messages within the mailbox. > > Initially defined in RFC 4551, The Conditional Store facility > provides a protected update mechanism for message state information > and a mechanism for requesting only changes to message state. This > memo updates that mechanism and obsoletes RFC 4551, based on > operational experience. > > This document additionally updates another IMAP extension, Quick > Resynchronization, which builds on the Conditional Store extension to > provide an IMAP client the ability to fully resynchronize a mailbox > as part of the SELECT/EXAMINE command, without the need for > additional server-side state or client round-trips. Hence this memo > obsoletes RFC 5162. > > Finally, this document also updates the line length recommendation in > Section 3.2.1.5 of RFC 2683. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From ietf-secretariat-reply@ietf.org Wed Jan 22 10:44:05 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAFA1A03B6 for ; Wed, 22 Jan 2014 10:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFkLxzHE32RZ; Wed, 22 Jan 2014 10:44:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3D1A03C1; Wed, 22 Jan 2014 10:44:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: qresync-chairs@tools.ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org, imapext@Ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122184404.9570.66299.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 10:44:04 -0800 From: IETF Secretariat X-Mailman-Approved-At: Wed, 22 Jan 2014 18:48:41 -0800 Subject: [imapext] ID Tracker State Update Notice: X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 18:44:05 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162b= is/ From iesg-secretary@ietf.org Mon Jan 27 00:11:53 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34741A005E; Mon, 27 Jan 2014 00:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkuy4u8gTTct; Mon, 27 Jan 2014 00:11:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2141A0038; Mon, 27 Jan 2014 00:11:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: DraftTracker Mail System To: iesg@ietf.org, qresync-chairs@tools.ietf.org, draft-ietf-qresync-rfc5162bis@tools.ietf.org, imapext@Ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127081152.20769.408.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 00:11:52 -0800 Cc: iesg-secretary@ietf.org Subject: [imapext] Last Call Expired: X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 08:11:54 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162b= is/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From lear@cisco.com Mon Jan 27 05:20:58 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F15B1A020E; Mon, 27 Jan 2014 05:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfVPqbDkO5jQ; Mon, 27 Jan 2014 05:20:57 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 782CE1A020A; Mon, 27 Jan 2014 05:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3184; q=dns/txt; s=iport; t=1390828855; x=1392038455; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=z0yW11rgQCG4ugwACOvVUpM4Ma+Riefv+tmp1OKfZRo=; b=PVYiBNlNngqbMRMUmJnaSAGOVmsBFtP8p4hWO7dy9PsTj80DgG7H5gWi j8S7DD6dKfvRtKNbdTlowtqPPo3LQ61lbY9uJ0nbTQ55qAFIcTJTqMADu VGyGW/vcHA/+CP5r0USkjrHAZU4NoDEz13t/yZpV0g+nnJiUu2Q97yJTX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJdc5lKQ/khM/2dsb2JhbABZgww4g1O5WIENFnSCJQEBAQMBI1UBEAsUBAICBRYLAgIJAwIBAgErGgYBDAEHAQGHeQgNq1KcWheBKYtxgSBTB4JvgUkBA5gngTKQbIMuO4E1 X-IronPort-AV: E=Sophos;i="4.95,729,1384300800"; d="scan'208";a="3576971" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 27 Jan 2014 13:20:53 +0000 Received: from mctiny.local ([10.61.174.53]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RDKqKK031965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 13:20:53 GMT Message-ID: <52E65878.9030906@cisco.com> Date: Mon, 27 Jan 2014 14:00:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Black, David" , "Alexey Melnikov (alexey.melnikov@isode.com)" , "dcridland@arcode.com" , "General Area Review Team (gen-art@ietf.org)" References: <8D3D17ACE214DC429325B2B98F3AE712026F1621C1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026F1621C1@MX15A.corp.emc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Barry Leiba \(barryleiba@computer.org\)" , "ietf@ietf.org" , "imapext@ietf.org" Subject: Re: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:20:58 -0000 Hi Dave, First, thank you for your review. I personally appreciate to the time you put in to all of your reviews. On 1/27/14, 3:06 AM, Black, David wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-qresync-rfc5162bis-09 > Reviewer: David L. Black > Review Date: January 26, 2014 > IETF LC End Date: January 27, 2014 > > Summary: > This draft is basically ready for publication, but has minor issues that > should be fixed before publication. > > This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162 > (IMAP Quick Mailbox Resynchronization) into a single document and makes > a few minor updates. It also updates the command line length > recommendation in RFC 2683 to support the longer command lines that > can occur with these extensions. > > As this is an update, I checked the diffs against RFC 4551 and RFC 5162; > they look reasonable. I found one minor issue that should be relatively > easy to address. > > Minor Issues: > > The command line length change in Section 4 applies to all IMAP commands, > and hence affects old servers, including those that don't implement either > of the extensions in this draft. That raises a backwards compatibility > concern - what happens when a new client sends a > 1000 character command > line to an old server that isn't expecting more than 1000 characters? As the draft indicates, this is problematic for the two extensions in question. We have discussed this limitation in the working group, and nobody seems to be concerned. That's due to two factors, I think: first, RFC 2683 is not normative (informational). I am unaware of any strict line length limitation in RFC 3501, for instance. Instead, there is a requirement for strict syntax parsing. If the client blows it in any way, the server SHOULD return an error with a BAD response. This having been said, while the working group has discussed this matter, it would be good to hear any additional voices of concern, in the interests of interoperability. This takes us to your next point: > > One possibility would be to apply the larger length recommendation only > after the client determines that the server supports at least one of > these extensions. > > Nits/editorial comments: > > The update to RFC 2683 would be easier to find from the table of contents > if the title of Section 4 were changed to "Long Command Lines (Update to > RFC 2683)". > > idnits 2.13.01 got confused by the command line examples, and flagged a > downref: > > ** Downref: Normative reference to an Informational RFC: RFC 2683 > > That downref appears to be ok and intended, as noted in the shepherd's > writeup. This will be addressed in a forthcoming update. Barry has "educated" us that really this is NOT an update to RFC2683, where the advice given in that document is superceded by a specific option. As such, this error will evaporate. From alexey.melnikov@isode.com Mon Jan 27 09:41:44 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BFC1A0290; Mon, 27 Jan 2014 09:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcNTaKPShegQ; Mon, 27 Jan 2014 09:41:41 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C21331A0251; Mon, 27 Jan 2014 09:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1390844497; d=isode.com; s=selector; i=@isode.com; bh=C18uM+P5IrqBZjvicy6HsYMmV/FIf/YMEFq48laZPNU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gKHDuaWsygTzN5F1hpI/js9w5Bf4oEarrulJGwZKfYx4gyajH7B8OrhX9AQRGAQdXWPuY1 iL3aivay/zUhf/AYd6W78Aj8agaGuIoCFueBz0PtkPQoS7WFyFYkcJqWKnp048UySeQWCa +xn1rZoB2yoRy6U/Fac/FmT+bkFbOYc=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 27 Jan 2014 17:41:37 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52E69A54.9030104@isode.com> Date: Mon, 27 Jan 2014 17:41:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Eliot Lear References: <8D3D17ACE214DC429325B2B98F3AE712026F1621C1@MX15A.corp.emc.com> <52E65878.9030906@cisco.com> In-Reply-To: <52E65878.9030906@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dcridland@arcode.com" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "imapext@ietf.org" , "Barry Leiba \(barryleiba@computer.org\)" , "Black, David" Subject: Re: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 17:41:44 -0000 Hi Eliot, Mostly agreeing with you, but some corrections below: On 27/01/2014 13:00, Eliot Lear wrote: > Hi Dave, > > First, thank you for your review. I personally appreciate to the time > you put in to all of your reviews. > > On 1/27/14, 3:06 AM, Black, David wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-qresync-rfc5162bis-09 >> Reviewer: David L. Black >> Review Date: January 26, 2014 >> IETF LC End Date: January 27, 2014 >> >> Summary: >> This draft is basically ready for publication, but has minor issues that >> should be fixed before publication. >> >> This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162 >> (IMAP Quick Mailbox Resynchronization) into a single document and makes >> a few minor updates. It also updates the command line length >> recommendation in RFC 2683 to support the longer command lines that >> can occur with these extensions. >> >> As this is an update, I checked the diffs against RFC 4551 and RFC 5162; >> they look reasonable. I found one minor issue that should be relatively >> easy to address. >> >> Minor Issues: >> >> The command line length change in Section 4 applies to all IMAP commands, >> and hence affects old servers, including those that don't implement either >> of the extensions in this draft. That raises a backwards compatibility >> concern - what happens when a new client sends a > 1000 character command >> line to an old server that isn't expecting more than 1000 characters? > As the draft indicates, this is problematic for the two extensions in > question. We have discussed this limitation in the working group, and > nobody seems to be concerned. That's due to two factors, I think: > first, RFC 2683 is not normative (informational). I don't think this actually matters, but the rest of your argument is still valid. > I am unaware of any > strict line length limitation in RFC 3501, for instance. Instead, there > is a requirement for strict syntax parsing. If the client blows it in > any way, the server SHOULD return an error with a BAD response. That is very true. This is what happens now. > This having been said, while the working group has discussed this > matter, it would be good to hear any additional voices of concern, in > the interests of interoperability. Agreed. > This takes us to your next point: > >> One possibility would be to apply the larger length recommendation only >> after the client determines that the server supports at least one of >> these extensions. >> >> Nits/editorial comments: >> >> The update to RFC 2683 would be easier to find from the table of contents >> if the title of Section 4 were changed to "Long Command Lines (Update to >> RFC 2683)". >> >> idnits 2.13.01 got confused by the command line examples, and flagged a >> downref: >> >> ** Downref: Normative reference to an Informational RFC: RFC 2683 >> >> That downref appears to be ok and intended, as noted in the shepherd's >> writeup. > This will be addressed in a forthcoming update. Barry has "educated" us > that really this is NOT an update to RFC2683, where the advice given in > that document is superceded by a specific option. As such, this error > will evaporate. Actually, I think I convinced Barry that it is updating RFC 2683. Best Regards, Alexey From david.black@emc.com Sun Jan 26 18:07:12 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806981A0177; Sun, 26 Jan 2014 18:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYbdt8fMIrWX; Sun, 26 Jan 2014 18:07:10 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id DC25E1A017F; Sun, 26 Jan 2014 18:07:09 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0R272eN009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jan 2014 21:07:04 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0R272eN009869 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390788424; bh=NTNbS+noRA1hBvvbiBuOg2FrqTY=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rY2IROtckpBIBAobnn1MktvIui+paBtFv70Frg6GtgN14Y+ikpSrasrkCvH8Y9/EU fME+qFSf4485+KN9dVCGs2sT+jLcTU6Kld4rv5z+nmiDsMy7h3wOX1OYTLoocBuzTU v2ylUXkxXwLIuhBCeXwq3QeeB6a6vCJ8to6Kwtjg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0R272eN009869 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Sun, 26 Jan 2014 21:06:56 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0R26tat031811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jan 2014 21:06:56 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Sun, 26 Jan 2014 21:06:54 -0500 From: "Black, David" To: "Alexey Melnikov (alexey.melnikov@isode.com)" , "dcridland@arcode.com" , "General Area Review Team (gen-art@ietf.org)" Date: Sun, 26 Jan 2014 21:06:53 -0500 Thread-Topic: Gen-ART review of draft-ietf-qresync-rfc5162bis-09 Thread-Index: Ac8bBHAYj1adCBYhQu2KINJ+hxA0mA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F1621C1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public, Resumes X-Mailman-Approved-At: Mon, 27 Jan 2014 11:27:44 -0800 Cc: "Black, David" , "Barry Leiba \(barryleiba@computer.org\)" , "ietf@ietf.org" , "imapext@ietf.org" Subject: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 02:07:12 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-qresync-rfc5162bis-09 Reviewer: David L. Black Review Date: January 26, 2014 IETF LC End Date: January 27, 2014 Summary: This draft is basically ready for publication, but has minor issues that should be fixed before publication. This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162 (IMAP Quick Mailbox Resynchronization) into a single document and makes a few minor updates. It also updates the command line length recommendation in RFC 2683 to support the longer command lines that can occur with these extensions. As this is an update, I checked the diffs against RFC 4551 and RFC 5162; they look reasonable. I found one minor issue that should be relatively easy to address. Minor Issues: The command line length change in Section 4 applies to all IMAP commands, and hence affects old servers, including those that don't implement either of the extensions in this draft. That raises a backwards compatibility concern - what happens when a new client sends a > 1000 character command line to an old server that isn't expecting more than 1000 characters? One possibility would be to apply the larger length recommendation only after the client determines that the server supports at least one of these extensions. Nits/editorial comments: The update to RFC 2683 would be easier to find from the table of contents if the title of Section 4 were changed to "Long Command Lines (Update to RFC 2683)". idnits 2.13.01 got confused by the command line examples, and flagged a downref: ** Downref: Normative reference to an Informational RFC: RFC 2683 That downref appears to be ok and intended, as noted in the shepherd's writeup. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Mon Jan 27 06:21:04 2014 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FDF1A0231; Mon, 27 Jan 2014 06:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k4CV4Q1QIzT; Mon, 27 Jan 2014 06:21:02 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id D4A081A0214; Mon, 27 Jan 2014 06:21:01 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0REKLUO005722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 09:20:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0REKLUO005722 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390832424; bh=2TDDdpW2GAOoDonVpmg7CzXjIek=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=CDhHkLolIvVEg8Kcj/wWVR+cv+5cmANArOcKK6i9IszzUwSTv3Qnh+TcGKcpKM80Z uVyJzzkBzaHwzp5SQ2GsMVI9FamanA170cziXAtFXPOJc9FsldCMC4VAuu2WfXkE2D kw4nR0ylR6eUm3OXLcP2REdli60Ft8d0r27H92EI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0REKLUO005722 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor); Mon, 27 Jan 2014 09:20:13 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0REKCKA001772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 09:20:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Mon, 27 Jan 2014 09:19:47 -0500 From: "Black, David" To: Eliot Lear , "Alexey Melnikov (alexey.melnikov@isode.com)" , "dcridland@arcode.com" , "General Area Review Team (gen-art@ietf.org)" Date: Mon, 27 Jan 2014 09:20:10 -0500 Thread-Topic: Gen-ART review of draft-ietf-qresync-rfc5162bis-09 Thread-Index: Ac8bYuepHQKAPJ5wQ42zaOAlQX1aAAAB1PLg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026F162227@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026F1621C1@MX15A.corp.emc.com> <52E65878.9030906@cisco.com> In-Reply-To: <52E65878.9030906@cisco.com> 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-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 27 Jan 2014 11:27:44 -0800 Cc: "Black, David" , "Barry Leiba \(barryleiba@computer.org\)" , "ietf@ietf.org" , "imapext@ietf.org" Subject: Re: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: ,