From tss@iki.fi Sun Aug 12 22:01:36 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 CF91521F8569 for ; Sun, 12 Aug 2012 22:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.194 X-Spam-Level: X-Spam-Status: No, score=-108.194 tagged_above=-999 required=5 tests=[AWL=-2.272, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYPE13gCHfPv for ; Sun, 12 Aug 2012 22:01:36 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34621F856D for ; Sun, 12 Aug 2012 22:01:22 -0700 (PDT) Received: from [192.168.10.2] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id B4C831AE87C3 for ; Mon, 13 Aug 2012 08:01:21 +0300 (EEST) Message-ID: <1344834080.19913.106.camel@hurina> From: Timo Sirainen To: lemonade@ietf.org Date: Mon, 13 Aug 2012 08:01:20 +0300 Organization: Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.2.2-1+b1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: [lemonade] NOTIFY + CONTEXT 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, 13 Aug 2012 05:01:36 -0000 Just wondering if I understood this feature correctly..: RFC says: > No untagged FETCH response SHOULD be returned if a message becomes a > member of UPDATE SEARCH due to flag or annotation changes. This basically means that only new messages get FETCH responses, right? It also means that doing this wouldn't be very useful: a SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER])) FLAGGED because the only time it would return the header is when a message was saved/copied to the mailbox with the \Flagged flag already set. I guess the only use case would be when you want to get pushed FETCH replies for new messages that match a search query. So a client can add a NOTIFY and multiple SEARCH UPDATEs, each one pushing FETCH updates about new mails. From wwwrun@rfc-editor.org Thu Aug 16 07:26: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 366D121F85AE for ; Thu, 16 Aug 2012 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 FRN70+b8hhF8 for ; Thu, 16 Aug 2012 07:26:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 69D5121F85AC for ; Thu, 16 Aug 2012 07:26:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9762772E002; Thu, 16 Aug 2012 07:25:09 -0700 (PDT) To: Alexey.Melnikov@isode.com, dave.cridland@isode.com, corby@computer.org, barryleiba@computer.org, presnick@qualcomm.com, gparsons@nortel.com, eburger@standardstrack.com From: RFC Errata System Message-Id: <20120816142509.9762772E002@rfc-editor.org> Date: Thu, 16 Aug 2012 07:25:09 -0700 (PDT) Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] [Technical Errata Reported] RFC5162 (3322) 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: Thu, 16 Aug 2012 14:26:42 -0000 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=3322 -------------------------------------- Type: Technical Reported by: Jan Kundrát Section: 3.6 Original Text ------------- A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command or because messages were expunged in other connections (i.e., the VANISHED response without the EARLIER tag) also decrements the number of messages in the mailbox; it is not necessary for the server to send an EXISTS response with the new value. It also decrements message sequence numbers for each successive message in the mailbox (see the example at the end of this section). Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections SHOULD only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers SHOULD NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command. Note that client implementors must take care to properly decrement the number of messages in the mailbox even if a server violates this last SHOULD or repeats the same UID multiple times in the returned UID set. In general, this means that a client using this extension should either avoid using message numbers entirely, or have a complete mapping of UIDs to message sequence numbers for the selected mailbox. Corrected Text -------------- A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command or because messages were expunged in other connections (i.e., the VANISHED response without the EARLIER tag) also decrements the number of messages in the mailbox; it is not necessary for the server to send an EXISTS response with the new value. It also decrements message sequence numbers for each successive message in the mailbox (see the example at the end of this section). Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections MUST only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers MUST NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are expunged. Notes ----- If the servers were allowed to send VANISHED responses referring to non-existing UIDs, there's a possible race condition when new arrivals are expunged. This is due to the sequence-UID assymetry of EXISTS vs. VANISHED. New arrivals are reported through EXISTS and their UIDs are not known to the client. Suppose the following scenario where two messages exist and their UIDs are 10 and 11. Two more messages arrive: * 4 EXISTS * VANISHED 12:20 The client has no way of knowing whether the two new arrivals have UIDs falling into the 12:20 range. As such, the client doesn't know whether there are two, three or four messages in the mailbox at this point. See http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001781.html for details. 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 wwwrun@rfc-editor.org Thu Aug 16 07:48:39 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 DD33921F84E4 for ; Thu, 16 Aug 2012 07:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 9CyGAx4PvmxS for ; Thu, 16 Aug 2012 07:48:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54021F85C6 for ; Thu, 16 Aug 2012 07:48:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3F97A72E004; Thu, 16 Aug 2012 07:47:07 -0700 (PDT) To: Alexey.Melnikov@isode.com, dave.cridland@isode.com, corby@computer.org, barryleiba@computer.org, presnick@qualcomm.com, gparsons@nortel.com, eburger@standardstrack.com From: RFC Errata System Message-Id: <20120816144707.3F97A72E004@rfc-editor.org> Date: Thu, 16 Aug 2012 07:47:07 -0700 (PDT) Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [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: Thu, 16 Aug 2012 14:48:40 -0000 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 ned.freed@mrochek.com Fri Aug 17 08:05:10 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 C9B8721F842B for ; Fri, 17 Aug 2012 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] 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 f1t7cH+2MKYw for ; Fri, 17 Aug 2012 08:05:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4E621F841E for ; Fri, 17 Aug 2012 08:05:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJ5HNX9R1S007RS3@mauve.mrochek.com> for lemonade@ietf.org; Fri, 17 Aug 2012 07:59:54 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIXJBO9M4W0006TF@mauve.mrochek.com>; Fri, 17 Aug 2012 07:59:50 -0700 (PDT) Message-id: <01OJ5HNUWQK20006TF@mauve.mrochek.com> Date: Fri, 17 Aug 2012 07:56:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 16 Aug 2012 07:47:07 -0700 (PDT)" <20120816144707.3F97A72E004@rfc-editor.org> References: <20120816144707.3F97A72E004@rfc-editor.org> To: RFC Errata System Cc: gparsons@nortel.com, lemonade@ietf.org, corby@computer.org, dave.cridland@isode.com, presnick@qualcomm.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, rfc-editor@rfc-editor.org 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: Fri, 17 Aug 2012 15:05:11 -0000 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. Ned > 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 eburger@standardstrack.com Fri Aug 17 08:07:58 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 EB78811E80D5 for ; Fri, 17 Aug 2012 08:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 pLYHgHvmNwdx for ; Fri, 17 Aug 2012 08:07:58 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5011E80A5 for ; Fri, 17 Aug 2012 08:07:58 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:61260 helo=[192.168.15.138]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T2O9T-0002GS-HN; Fri, 17 Aug 2012 08:07:56 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-33--310832340; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <01OJ5HNUWQK20006TF@mauve.mrochek.com> Date: Fri, 17 Aug 2012 11:07:51 -0400 Message-Id: References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> To: RFC Errata System X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Resnick Pete , lemonade@ietf.org, Leiba Barry 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: Fri, 17 Aug 2012 15:07:59 -0000 --Apple-Mail-33--310832340 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The submitter says it themselves: > If this errata gets accepted, it will require rather heavy editing of = the document That sounds like a revision of the document, not just an editorial = errata. On Aug 17, 2012, at 10:56 AM, 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. >=20 > 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. >=20 > Ned >=20 >> The following errata report has been submitted for RFC5162, >> "IMAP4 Extensions for Quick Mailbox Resynchronization". >=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5162&eid=3D3323 >=20 >> -------------------------------------- >> Type: Technical >> Reported by: Jan Kundr=E1t >=20 >> Section: GLOBAL >=20 >> 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. >=20 >> 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. >=20 >> 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. >=20 >> 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. >=20 >> 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. >=20 >> -------------------------------------- >> 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 >=20 --Apple-Mail-33--310832340 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODE3MTUwNzUxWjAjBgkqhkiG9w0BCQQxFgQU tz5x8sdngPUBFkHIPLcABHhINuUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAITAiHHspNTCB+RMZm6ry5xDaW6tIVwkJWFA225taDHtn8pCcRJHd cXyoIj8+lJHA/igj6bZBFoQZ8HwvC5mfWyzuBEa9nN2Kg77kgnidKoIXjITWcBo02Oxrgf/FP5r1 2SWmq8fA+Jp5fcJsAKcTSbJs2DdI7Hr08GmDXdE4Vb/LJaKY+diqAFXFdEkGgtoXKQf1yZY1Jlxt ghS+y4AoROHtehbZT3jiP9M6UnrjWoN0B7ToyNJydEl5cd46692555Gv7nvgdrcIdtRgOLrF8NVn PcO+KPFSxryScK3YNZ5Yf7FaLurDCtgU9WnQAXHylQvDGHMIrV8DyMXmdd3jzQAAAAAAAA== --Apple-Mail-33--310832340-- From alexey.melnikov@isode.com Fri Aug 17 08:11:40 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 5751B21F849D for ; Fri, 17 Aug 2012 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 i43H4HwfsCb2 for ; Fri, 17 Aug 2012 08:11:39 -0700 (PDT) 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 0DDDC21F846A for ; Fri, 17 Aug 2012 08:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345216297; d=isode.com; s=selector; i=@isode.com; bh=AXnV1meJ3pZkwpPa26ZhG7+/FBvSlV2eRsocuoygJxQ=; 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=k//ohHRa+fZQfwlcoOQlRh213BAkHqvInNyQZl8LKuFHFzVHBaEWyxUhM1V43AwNBid7yS KYDZmbDHl0gRfy4ziA0GjkFmWv1FfRrtN9+zq9Txcf3CImsdM2fCSZJMsMO3a+kIGbatHV Jk2yiuVMWm1jk3ya0/jAdbEk/xLLprA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 17 Aug 2012 16:11:37 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502E5F66.1080804@isode.com> Date: Fri, 17 Aug 2012 16:12:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Ned Freed References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> In-Reply-To: <01OJ5HNUWQK20006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: gparsons@nortel.com, lemonade@ietf.org, corby@computer.org, dave.cridland@isode.com, presnick@qualcomm.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: Fri, 17 Aug 2012 15:11:40 -0000 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'l= l > defer to Barry on that. I think the use of SHOULD is correct, because we wanted this behaviour=20 to be per mailbox (and not necessarily server wide). So I think a=20 different change is needed and I will try to suggest some alternative=20 change later on. I am also open to suggestions on whether people would like me to work on=20 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 means t= hat 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 through= out 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 Resynchronizatio= n >> Publication Date : March 2008 >> Author(s) : A. Melnikov, D. Cridland, C. Wilson >> Category : PROPOSED STANDARD >> Source : Enhancements to Internet email to support diverse s= ervice environments >> Area : Applications >> Stream : IETF >> Verifying Party : IESG From jkt@flaska.net Fri Aug 17 08:19:56 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 8A93711E80D7 for ; Fri, 17 Aug 2012 08:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 13A2oshDGGWz for ; Fri, 17 Aug 2012 08:19:56 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91211E80D5 for ; Fri, 17 Aug 2012 08:19:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABxgLlCT5xpZ/2dsb2JhbABFhgG0OYEHgiABAQUjDwEFQAEQCw4KAgIFFgsCAgkDAgECAUUGDQEHAQGICQunBpMugSGKBIVPgRIDlU+BFI5+gmKBXw X-IronPort-AV: E=Sophos;i="4.77,785,1336341600"; d="scan'208";a="223254" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 17 Aug 2012 17:19:53 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id A47D83DA82; Fri, 17 Aug 2012 17:19:53 +0200 (CEST) Message-ID: <502E6100.1040208@flaska.net> Date: Fri, 17 Aug 2012 17:19:28 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: Eric Burger References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Resnick Pete , lemonade@ietf.org, Leiba Barry , 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: Fri, 17 Aug 2012 15:19:56 -0000 On 08/17/12 17:07, Eric Burger wrote: > The submitter says it themselves: >> If this errata gets accepted, it will require rather heavy editing of the document > > That sounds like a revision of the document, not just an editorial errata. Before filing the errata, I wrote a draft proposal [1] (not submitted at the time due to the submission form being closed) fixing both of the erratas I submitted yesterday. In the subsequent discussion, I was pointed to the errata form as the best way to proceed. I'm obviously very unfamiliar with the process, but I'm just trying to fix a real problem with the QRESYNC extension. Going either the way of erratas or proceeding though a new revision of the extension are both fine by me, and I'll be happy to contribute to the eventual -bis RFC as well. With kind regards, Jan [1] http://trojita.flaska.net/draft-imap-qresync-arrived-01.html -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From jkt@flaska.net Fri Aug 17 08:26:56 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 BFE0721F853B for ; Fri, 17 Aug 2012 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 DvOl+1oqp5P2 for ; Fri, 17 Aug 2012 08:26:56 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id E0EAA21F8535 for ; Fri, 17 Aug 2012 08:26:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH5iLlCT5xpZ/2dsb2JhbABFhgG0OYEHgiABAQUjFUARCxgCAgUWCwICCQMCAQIBRRMIAQGICacNkzCBIYoDAYNFggqBEgOVT4EUjn6CYoFf X-IronPort-AV: E=Sophos;i="4.77,785,1336341600"; d="scan'208";a="223288" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 17 Aug 2012 17:26:54 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id DAFE13DA82 for ; Fri, 17 Aug 2012 17:26:54 +0200 (CEST) Message-ID: <502E62A6.5000801@flaska.net> Date: Fri, 17 Aug 2012 17:26:30 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: lemonade@ietf.org 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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 17 Aug 2012 15:26:56 -0000 On 08/17/12 17:12, Alexey Melnikov wrote: > 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. (Going just to lemonade for the technical discussion.) From how I understand the wording, the "ENABLE QRESYNC" is enough to tell the server that it SHOULD send VANISHED instead of EXPUNGE, and also the sole reason for why is ENABLE QRESYNC needed at all (because if the mailbox was selected previously, one could easily use SELECT ... QRESYNC ... to activate this extension and hence indicate that VANISHED is expected). Or is it due to the possibility of having mail stores for which the server cannot report UIDs which are expunged *while* the mailbox is selected, but can report their sequence numbers just fine? Is that a likely scenario? With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From alexey.melnikov@isode.com Fri Aug 17 08:36:03 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 57EB121F85D2 for ; Fri, 17 Aug 2012 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=-0.249, 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 GKKxcyJg91hI for ; Fri, 17 Aug 2012 08:36:01 -0700 (PDT) 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 B8AC321F85D1 for ; Fri, 17 Aug 2012 08:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345217760; d=isode.com; s=selector; i=@isode.com; bh=s5QZSKLI8st6s8j8vG2UnH+JYJfk8cKYsiojCYuQWAc=; 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=ompUXkAXIzRe0WOx1rOp9DyjXBkTCUOBevOpVoBokWLWWj1QjDgcxKbj6y6croEwZrkcKN 3+//gTyZVzOd6F+nwLXXh3E/w8SMZuloqtYn+t6L2Sw+4pOmK2CNtTuj9g+nCWfWVQEhVh HHjRxIDXTDbT/j1aoleF5u2uBIKD3j4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 17 Aug 2012 16:36:00 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502E651F.1080903@isode.com> Date: Fri, 17 Aug 2012 16:37:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: lemonade@ietf.org References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E6100.1040208@flaska.net> In-Reply-To: <502E6100.1040208@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable 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: Fri, 17 Aug 2012 15:36:03 -0000 On 17/08/2012 16:19, Jan Kundr=E1t wrote: > On 08/17/12 17:07, Eric Burger wrote: >> The submitter says it themselves: >>> If this errata gets accepted, it will require rather heavy editing=20 >>> of the document >> >> That sounds like a revision of the document, not just an editorial=20 >> errata. > > Before filing the errata, I wrote a draft proposal [1] (not submitted=20 > at the time due to the submission form being closed) fixing both of=20 > the erratas I submitted yesterday. In the subsequent discussion, I was=20 > pointed to the errata form as the best way to proceed. Indeed, I encouraged Jan to submit the errata. > I'm obviously very unfamiliar with the process, but I'm just trying to=20 > fix a real problem with the QRESYNC extension. Going either the way of=20 > erratas or proceeding though a new revision of the extension are both=20 > fine by me, and I'll be happy to contribute to the eventual -bis RFC=20 > as well. > > With kind regards, > Jan > > [1] http://trojita.flaska.net/draft-imap-qresync-arrived-01.html From tss@iki.fi Fri Aug 17 09:11:25 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 F1EB521F848A for ; Fri, 17 Aug 2012 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.291 X-Spam-Level: X-Spam-Status: No, score=-110.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 ed11nLulyT42 for ; Fri, 17 Aug 2012 09:11:23 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5974811E80D1 for ; Fri, 17 Aug 2012 09:11:23 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id D6F6F1AE87E9; Fri, 17 Aug 2012 19:11:21 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Timo Sirainen In-Reply-To: <502E62A6.5000801@flaska.net> Date: Fri, 17 Aug 2012 19:11:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <86D46CBC-447D-477E-8289-74FAFBC1BFD7@iki.fi> References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E5F66.1080804@isode.com> <502E62A6.5000801@flaska.net> To: =?iso-8859-1?Q?Jan_Kundr=E1t?= X-Mailer: Apple Mail (2.1084) Cc: lemonade@ietf.org 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: Fri, 17 Aug 2012 16:11:26 -0000 On 17.8.2012, at 18.26, Jan Kundr=E1t wrote: > On 08/17/12 17:12, Alexey Melnikov wrote: >> 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. >=20 > (Going just to lemonade for the technical discussion.) >=20 > =46rom how I understand the wording, the "ENABLE QRESYNC" is enough to = tell the server that it SHOULD send VANISHED instead of EXPUNGE, and = also the sole reason for why is ENABLE QRESYNC needed at all (because if = the mailbox was selected previously, one could easily use SELECT ... = QRESYNC ... to activate this extension and hence indicate that VANISHED = is expected). >=20 > Or is it due to the possibility of having mail stores for which the = server cannot report UIDs which are expunged *while* the mailbox is = selected, but can report their sequence numbers just fine? Is that a = likely scenario? I'm guessing the idea was to allow QRESYNC for some mailboxes, but not = for others that don't support modseqs. That's reasonable, but I don't = really see how a server couldn't be able to send proper VANISHED = replies. Or I guess if the server does dummy proxying for some selected = mailboxes, but that would also have problems with other extensions.= From barryleiba@gmail.com Fri Aug 17 09:37:43 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 B533921F8530 for ; Fri, 17 Aug 2012 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 nVfcmZ3r3c0M for ; Fri, 17 Aug 2012 09:37:43 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8F21F852E for ; Fri, 17 Aug 2012 09:37:43 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4599405ghb.31 for ; Fri, 17 Aug 2012 09:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XIcxwfoYrd36xEnmWBEAydC8wsc4zgUeqdUfuQV+TVE=; b=J/N34tykDakM/j6MPMF9ig6Xp6qHVEsGvqF0katavqwP3V2a5vaLKp569bQQtruQMu rbssIwWzGAzcyzkZ0Dqkznc7Sc4Jew5Ul+HgkQLnAb6f0pIkX0QzXRclv0zCX++T6wv5 Lppgkzl10ilyXHsNuYwKCM6gulWMf7QxIwxXj5ayjZ4BlxhBGQpzOH+pLejuWDqck4hf x18GuYO1lgrr8PcMgf6ddQTaFRZH2XiApIsX6uNbC/FnJPVcwcvIgDG0b7d9BJsGKVb2 Ms6fi3SHYNHWlHgNGbqEpK5XuMwkBoDxq2FF1AfY/b7fUBy95GZMXY5ZrYdZ30opz+fV p+Mg== MIME-Version: 1.0 Received: by 10.60.169.100 with SMTP id ad4mr4498454oec.21.1345221462763; Fri, 17 Aug 2012 09:37:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.76.154.9 with HTTP; Fri, 17 Aug 2012 09:37:42 -0700 (PDT) In-Reply-To: <502E6100.1040208@flaska.net> References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E6100.1040208@flaska.net> Date: Fri, 17 Aug 2012 12:37:42 -0400 X-Google-Sender-Auth: M5-uSX4Y7BdYGPOqZK6QtGC6Av4 Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Resnick Pete , lemonade@ietf.org, Alexey Melnikov , 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: Fri, 17 Aug 2012 16:37:43 -0000 > Before filing the errata, I wrote a draft proposal [1] (not submitted at the > time due to the submission form being closed) fixing both of the erratas I > submitted yesterday. In the subsequent discussion, I was pointed to the > errata form as the best way to proceed. Ooh, bad advice. I'm sorry you're caught in the middle of that; you shouldn't be. But, yes, the errata system is meant to be used *only* for things that were truly *errors* in the publishing of the original spec -- that is, things that would have been considered errors at the time, but didn't get caught. This is an issue where you think something should have been done differently. You might be right, but it's not for "errata". What I *should* do is reject this erratum, though I do have the option of marking it "held for document update", by way of recording the issue. We (the IESG) are strongly trying to avoid doing that, because the errata system isn't mean to be an issue tracker. So I really prefer to reject it. Alexey has asked that I not reject it just yet, so I'll leave it open for now. For now. > I'm obviously very unfamiliar with the process, I understand, and, as I say, I'm sorry to get you caught up in a silly "process" thing. Let's try to move it in the right direction. > but I'm just trying to fix a > real problem with the QRESYNC extension. Going either the way of erratas or > proceeding though a new revision of the extension are both fine by me, and > I'll be happy to contribute to the eventual -bis RFC as well. I would like to see Alexey and Jan work on a revision of the RFC, which we can handle through the appsawg. Barry, Applications AD From ned.freed@mrochek.com Fri Aug 17 09:39:06 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 02C5511E80D5 for ; Fri, 17 Aug 2012 09:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] 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 blTNqYDQOUph for ; Fri, 17 Aug 2012 09:39:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E978911E80D1 for ; Fri, 17 Aug 2012 09:39:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJ5KYKO8GW007BGR@mauve.mrochek.com> for lemonade@ietf.org; Fri, 17 Aug 2012 09:34:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIXJBO9M4W0006TF@mauve.mrochek.com>; Fri, 17 Aug 2012 09:33:57 -0700 (PDT) Message-id: <01OJ5KYISAY80006TF@mauve.mrochek.com> Date: Fri, 17 Aug 2012 09:30:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Aug 2012 11:07:51 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> To: Eric Burger Cc: Resnick Pete , lemonade@ietf.org, Leiba Barry , 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: Fri, 17 Aug 2012 16:39:06 -0000 > The submitter says it themselves: > > If this errata gets accepted, it will require rather heavy editing of the document Um, that was precisely what I was responding to. "Accepted" has a specific meaning in the context of errata. And the errata has to be dealt with no matter what is subsequently done to the document. That said, I find myself in agreement with Alexey as to how this should be handled. So I now believe this errata should be rejected on both process and technical grounds, and an alternate solution to the problem should be implemented in a document revision. Ned From jkt@flaska.net Sat Aug 18 06:16:35 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 6E87621F8551 for ; Sat, 18 Aug 2012 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 FcEw04A5Ueoe for ; Sat, 18 Aug 2012 06:16:34 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1A21F850C for ; Sat, 18 Aug 2012 06:16:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEJAMGUL1CT5xpZ/2dsb2JhbABFhTpHs0EEBHWBB4IgAQEFIxVAARALGAICBRMDCwICCQMCAQIBRQYNAQcBAYgJBAemdpJwgSGKBIVmgRIDlU+BFI5+gmKBXw X-IronPort-AV: E=Sophos;i="4.77,790,1336341600"; d="scan'208";a="225777" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 18 Aug 2012 15:16:32 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 39AAB3DA82; Sat, 18 Aug 2012 15:16:32 +0200 (CEST) Message-ID: <502F9596.1090502@flaska.net> Date: Sat, 18 Aug 2012 15:16:06 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: Barry Leiba References: <20120816144707.3F97A72E004@rfc-editor.org> <01OJ5HNUWQK20006TF@mauve.mrochek.com> <502E6100.1040208@flaska.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Resnick Pete , lemonade@ietf.org, Alexey Melnikov , 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: Sat, 18 Aug 2012 13:16:35 -0000 On 08/17/12 18:37, Barry Leiba wrote: > I would like to see Alexey and Jan work on a revision of the RFC, > which we can handle through the appsawg. I've therefore submitted my earlier draft, it lives on [1]. Please feel free to do anything you deem appropriate with the original errata. With kind regards Jan [1] http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/ -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From alexey.melnikov@isode.com Mon Aug 20 07:10:39 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 2437021F8678 for ; Mon, 20 Aug 2012 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 hTboRqM9JM47 for ; Mon, 20 Aug 2012 07:10:38 -0700 (PDT) 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 43A3321F8629 for ; Mon, 20 Aug 2012 07:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345471836; d=isode.com; s=selector; i=@isode.com; bh=MxncDFVCYOUFjhPrRTxoqjRsDQgv6girlCMQVzWdrpE=; 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=e2mpY7o2hRFSsfks0URik2lccixTeTquP99jbygaOmr7/m1GyUKYsxWS6JHZOs2AEccPfI qnKdsGGzHm/rgK15JV016rSuFOpa8K7aMN1qycVLlL7H5MGHT9KDa/qnaiOQzc+F40/5Rj 2wIrq9FQMoO/m+ze64fxqfAuazXcWPI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 20 Aug 2012 15:10:35 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <503245A1.8020404@isode.com> Date: Mon, 20 Aug 2012 15:11:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <1344834080.19913.106.camel@hurina> In-Reply-To: <1344834080.19913.106.camel@hurina> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: Re: [lemonade] NOTIFY + CONTEXT 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, 20 Aug 2012 14:10:39 -0000 On 13/08/2012 06:01, Timo Sirainen wrote: > Just wondering if I understood this feature correctly..: > > RFC says: > >> No untagged FETCH response SHOULD be returned if a message becomes a >> member of UPDATE SEARCH due to flag or annotation changes. > This basically means that only new messages get FETCH responses, right? Correct. I think it says that explicitly earlier in the same section. > It also means that doing this wouldn't be very useful: > > a SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER])) FLAGGED > > because the only time it would return the header is when a message was > saved/copied to the mailbox with the \Flagged flag already set. > > I guess the only use case would be when you want to get pushed FETCH > replies for new messages that match a search query. > > So a client can add a NOTIFY and multiple SEARCH UPDATEs, each one > pushing FETCH updates about new mails. From tss@iki.fi Wed Aug 29 13:00:14 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 BF05A21F85F4 for ; Wed, 29 Aug 2012 13:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fsJo9qf0oMgX for ; Wed, 29 Aug 2012 13:00:14 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27DAF21F85C4 for ; Wed, 29 Aug 2012 13:00:14 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id D63B31AE87C0 for ; Wed, 29 Aug 2012 23:00:12 +0300 (EEST) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2012 23:00:12 +0300 Message-Id: <93CF1554-2CFE-41CE-8E63-3DA5CB3523D4@iki.fi> To: lemonade@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [lemonade] CATENATE with 0 message size 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: Wed, 29 Aug 2012 20:00:14 -0000 a APPEND INBOX CATENATE (TEXT {0} ) This isn't explicitly prevented by the RFC. So I guess it means that the = TEXT {0} parts can be simply skipped. Regardless of the above, it's possible to also create empty URL streams = (e.g. a partial starting from offset 100000000). Should it be allowed to = save empty messages?.. I'm thinking I'll just return NO to such APPENDs, = although with MULTIAPPEND that's a bit bad behavior to abort the whole = APPEND.