From presnick@qti.qualcomm.com Mon Dec 10 09:22:08 2012 Return-Path: X-Original-To: lemonade@ietfa.amsl.com Delivered-To: lemonade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB121F8552 for ; Mon, 10 Dec 2012 09:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj0UN-sx6yKQ for ; Mon, 10 Dec 2012 09:22:01 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8046C21F8504 for ; Mon, 10 Dec 2012 09:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1355158510; x=1386694510; h=from:message-id:date:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1+3VtJoq30qIt91Fahgx+BQXbD9J4qAoalMdnj2AEKY=; b=ei0FU35XlEGqEl/hkSsKvrGS8mkhdtDDTBw8oNY+dEhO1Tc+D1QFGrPL J46ynyzl6pztPrHfkPElvn0T9QRxA2GQfofYb/uIXhpPLdV7saIrZ0J1M fcYEYsrmUQJFYzmPZ6eJB08o6POntNBhwR9YqNJ6sxR10AMJMNEwAJEdR o=; X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="11294650" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 10 Dec 2012 08:55:09 -0800 From: Pete Resnick X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="3541216" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Dec 2012 09:21:58 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 10 Dec 2012 09:21:57 -0800 Message-ID: <50C61A32.7010205@qualcomm.com> Date: Mon, 10 Dec 2012 11:21:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alexey Melnikov References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E5F66.1080804@isode.com> In-Reply-To: <502E5F66.1080804@isode.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Cc: Ned Freed , gparsons@nortel.com, lemonade@ietf.org, corby@computer.org, dave.cridland@isode.com, barryleiba@computer.org, RFC Errata System Subject: Re: [lemonade] [Technical Errata Reported] RFC5162 (3323) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:22:08 -0000 (Housekeeping) Should we be marking this as "Hold for Document Update" at this point, or reject it outright? pr On 8/17/12 10:12 AM, Alexey Melnikov wrote: > On 17/08/2012 15:56, Ned Freed wrote: >> Leaving aside the issue of whether or not this change is a good idea, >> this >> errata proposes changing a SHOULD to a MUST. It isn't possible to change >> compliance language in a specification with an errata - and it should be >> obvious why this is so. >> >> The most that can be done here is note this as a possible future >> revision. As >> to whether or not it is appropriate to use the errata system for >> such, I'll >> defer to Barry on that. > I think the use of SHOULD is correct, because we wanted this behaviour > to be per mailbox (and not necessarily server wide). So I think a > different change is needed and I will try to suggest some alternative > change later on. > > I am also open to suggestions on whether people would like me to work > on a -bis version of this document. > > In the meantime I would like to suggest that the erratum remains open > (and not rejected). >>> The following errata report has been submitted for RFC5162, >>> "IMAP4 Extensions for Quick Mailbox Resynchronization". >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5162&eid=3323 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Jan Kundrát >>> Section: GLOBAL >>> Original Text >>> ------------- >>> The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command >>> also tells the server that it SHOULD start sending VANISHED responses >>> (see Section 3.6) instead of EXPUNGE responses. >>> Corrected Text >>> -------------- >>> The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command >>> also tells the server that it MUST start sending VANISHED responses >>> (see Section 3.6) instead of EXPUNGE responses. >>> Notes >>> ----- >>> The explicit allowance for EXPUNGE being sent instead of VANISHED >>> means that clients still have to maintain a full sequence-to-UID >>> mapping, otherwise there is a risk of losing synchronization. Given >>> that QRESYNC itself is an optional extension, I find it hard to >>> imagine a case where the server cannot send a proper VANISHED response. >>> If this errata gets accepted, it will require rather heavy editing >>> of the document; the notion of EXPUNGE responses being allowed is >>> followed throughout the whole RFC, including the examples. >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> -------------------------------------- >>> RFC5162 (draft-ietf-lemonade-reconnect-client-06) >>> -------------------------------------- >>> Title : IMAP4 Extensions for Quick Mailbox >>> Resynchronization >>> Publication Date : March 2008 >>> Author(s) : A. Melnikov, D. Cridland, C. Wilson >>> Category : PROPOSED STANDARD >>> Source : Enhancements to Internet email to support >>> diverse service environments >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG > > From alexey.melnikov@isode.com Tue Dec 18 07:19:42 2012 Return-Path: X-Original-To: lemonade@ietfa.amsl.com Delivered-To: lemonade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB421F8A75 for ; Tue, 18 Dec 2012 07:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPeQ09Mok2F1 for ; Tue, 18 Dec 2012 07:19:41 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC921F892E for ; Tue, 18 Dec 2012 07:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355843970; d=isode.com; s=selector; i=@isode.com; bh=PdGjNL0svjlYWSsRqJdrmSXFDoM1swPMzELp6mDHEBE=; 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=bSc/F5a1kOZkFQFxj5hxFb6NI/F4s1UGaBusNM0ZsU5XfJZQCCCsnei0a4g3UPbExQ6r2x O4NZk5W4xyk0sc78VSZ8dxjccbUi6tWYl2UbO12gLsNbZnTK1B02JRffE4KaaaD2c0pfTu gnK4LjkUAi6UgpMLRMwUy44ceXyR4u0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 Dec 2012 15:19:30 +0000 Message-ID: <50D0898C.7000404@isode.com> Date: Tue, 18 Dec 2012 15:19:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Pete Resnick References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E5F66.1080804@isode.com> <50C61A32.7010205@qualcomm.com> In-Reply-To: <50C61A32.7010205@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: Ned Freed , gparsons@nortel.com, lemonade@ietf.org, corby@computer.org, dave.cridland@isode.com, barryleiba@computer.org, RFC Errata System Subject: Re: [lemonade] [Technical Errata Reported] RFC5162 (3323) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:19:42 -0000 On 10/12/2012 17:21, Pete Resnick wrote: > (Housekeeping) > > Should we be marking this as "Hold for Document Update" at this point,=20 > or reject it outright? Sorry for the delay, finally got in touch with Jan to discuss what to do=20 here. Either reject explaining in the rejection note that the issue is valid,=20 but the fix is not (and pointing to the new draft). Or "Hold for=20 Document Update". > pr > > On 8/17/12 10:12 AM, Alexey Melnikov wrote: >> On 17/08/2012 15:56, Ned Freed wrote: >>> Leaving aside the issue of whether or not this change is a good=20 >>> idea, this >>> errata proposes changing a SHOULD to a MUST. It isn't possible to=20 >>> change >>> compliance language in a specification with an errata - and it=20 >>> should be >>> obvious why this is so. >>> >>> The most that can be done here is note this as a possible future=20 >>> revision. As >>> to whether or not it is appropriate to use the errata system for=20 >>> such, I'll >>> defer to Barry on that. >> I think the use of SHOULD is correct, because we wanted this=20 >> behaviour to be per mailbox (and not necessarily server wide). So I=20 >> think a different change is needed and I will try to suggest some=20 >> alternative change later on. >> >> I am also open to suggestions on whether people would like me to work=20 >> on a -bis version of this document. >> >> In the meantime I would like to suggest that the erratum remains open=20 >> (and not rejected). >>>> The following errata report has been submitted for RFC5162, >>>> "IMAP4 Extensions for Quick Mailbox Resynchronization". >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5162&eid=3D3323 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Jan Kundr=E1t >>>> Section: GLOBAL >>>> Original Text >>>> ------------- >>>> The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command >>>> also tells the server that it SHOULD start sending VANISHED responses >>>> (see Section 3.6) instead of EXPUNGE responses. >>>> Corrected Text >>>> -------------- >>>> The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command >>>> also tells the server that it MUST start sending VANISHED responses >>>> (see Section 3.6) instead of EXPUNGE responses. >>>> Notes >>>> ----- >>>> The explicit allowance for EXPUNGE being sent instead of VANISHED=20 >>>> means that clients still have to maintain a full sequence-to-UID=20 >>>> mapping, otherwise there is a risk of losing synchronization. Given=20 >>>> that QRESYNC itself is an optional extension, I find it hard to=20 >>>> imagine a case where the server cannot send a proper VANISHED=20 >>>> response. >>>> If this errata gets accepted, it will require rather heavy editing=20 >>>> of the document; the notion of EXPUNGE responses being allowed is=20 >>>> followed throughout the whole RFC, including the examples. >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> -------------------------------------- >>>> RFC5162 (draft-ietf-lemonade-reconnect-client-06) >>>> -------------------------------------- >>>> Title : IMAP4 Extensions for Quick Mailbox=20 >>>> Resynchronization >>>> Publication Date : March 2008 >>>> Author(s) : A. Melnikov, D. Cridland, C. Wilson >>>> Category : PROPOSED STANDARD >>>> Source : Enhancements to Internet email to support=20 >>>> diverse service environments >>>> Area : Applications >>>> Stream : IETF >>>> Verifying Party : IESG