From nobody Sun Jan 3 21:35:35 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25813A167E for ; Sun, 3 Jan 2021 21:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 op8j7MqGXgav for ; Sun, 3 Jan 2021 21:35:32 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B1A3A0BF6 for ; Sun, 3 Jan 2021 21:35:32 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwIWg-000DlI-6Z; Mon, 04 Jan 2021 00:35:30 -0500 Date: Mon, 04 Jan 2021 00:35:25 -0500 From: John C Klensin To: ima@ietf.org, YAO Jiankang cc: ars-ads@ietf.org Message-ID: <71B5C1132B119F30CC7A5A7A@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 05:35:34 -0000 Today's New Year's bad news... Many of you who were around in 2011 and early 2012 will recall that there was a fairly extended discussion in the EAI WG about whether to retain the "UTF8SMTP" keyword used in the experimental versions of the protocol (documented in RFC 5336) and the standards track version (documented in RFC 6531). Primarily because the semantics of the extension and several things surrounding it had changed and systems (and those trying to debug mail transactions) should know exactly what they are asking for and agreeing to, the WG concluded that the extension keyword should be changed, the WG decided to change the extension name, ultimately to SMTPUTF8. Put differently, because the Experimental and Standards Track versions really were incompatible in important ways, the intent was to make it clear that the protocols were different. Because the reason for changing the extension keyword was to make it clear whether the Experimental or Standards Track protocols were being used, while it was, as far as I can remember or tell from minutes or my notes, never explicitly discussed, I believe the clear intent of the WG was that the keywords used in the WITH clause in time stamp trace fields use the new keyword form. For whatever reason, that didn't happen. AFAICT, other than being assigned a separate section number and introductory sentence, keywords in the IANA Considerations discussion of the WITH clause were carried forward unchanged from RFC 5336 even though SMTPUTF8 replaced UTF8SMTP in the Descriptions, leading to the potential for exactly the "which protocol is really in use?" question that the WG intended to avoid. I want to stress that the authors are not to blame for this. Every one of us who was involved with the WG during WG and IETF Last Call on what because RFC 6531 is equally responsible for not spotting the problem and insisting that the WG discuss it. The question is what we do about it today. >From a procedural standpoint, RFC 6531 is (only) a Proposed Standard and revising it to correct a clear mistake, especially a mistake that is inconsistent with the WG's reasoning in 2011, is entirely in order. From a more pragmatic standpoint, the questions are whether making the change at this point would be worth the disruption. If we are absolutely positive that there are no implementations of RFC 5336 left in the wild, the answer is probably not even those it means accepting long-term confusion between the extension keyword and the WITH values (a problem that, AFAIK, we don't have with any other SMTP extension. On the other hand, if we expect more SMTPUTF8 implementations in the future than we have today or if there might still be implementations of the Experimental protocol out there, changing/correcting the WITH keywords now would probably reduce confusion in the long terms and would be less painful now than later. Making the change, should we decide to do so, would require a one (substantive) page RFC explaining the WG's intent and requesting IANA change the keywords. I suppose, as a guilty party for not catching this a decade ago, I'm willing to write an post it. If we decide to note make the change, I might generate such an I-D anyway just to have a slightly more permanent/ available record than this note that the decision was explicit. What do people think? john From nobody Mon Jan 4 01:17:08 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672023A093D for ; Mon, 4 Jan 2021 01:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GE4jrDM3gR_q for ; Mon, 4 Jan 2021 01:17:04 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 009993A0936 for ; Mon, 4 Jan 2021 01:17:02 -0800 (PST) Received: from TestYJ-PC (unknown [218.241.103.64]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEAgJ3fJfyYKYAA--.17549S2; Mon, 04 Jan 2021 17:16:57 +0800 (CST) Date: Mon, 4 Jan 2021 17:16:57 +0800 From: "Jiankang Yao" To: "John C Klensin" , ima Cc: ars-ads Reply-To: Jiankang References: <71B5C1132B119F30CC7A5A7A@PSB> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <202101041715352454377@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart235750070600_=----" X-CM-TRANSID: AQAAf0AJEAgJ3fJfyYKYAA--.17549S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXr1UKry3Ary3GF45CrWxJFb_yoWrKr4kpF s3trsxKFZ8JryxCrn2yr4xX3Wayrs5Aa18tFnrtry8Awn8ZFyvyr1Fy34F9Fy8CrWfJa4j vryjyryUu3ZrAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Kb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAY jxAxZF0Ex2IqxwCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7 v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF 1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIx AIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0D MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4 xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUgMKuUUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 09:17:06 -0000 This is a multi-part message in MIME format. ------=_001_NextPart235750070600_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gSm9obiBhbmQgYWxsLA0KDQoNCiAgICAgSGFwcHkgTmV3IFllYXIgdG8gYWxsIQ0KICAg ICBUaGUgZmluYWwgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtZWFpLXJmYzUzMzZiaXMtMTYgDQogICAgIHdoaWNoIGtlZXBzIHRo ZSBmb2xsb3dpbmcgdGV4dDoNCg0KICAgfCAgV0lUSCAgICAgICB8IERlc2NyaXB0aW9uICAgICAg ICAgICAgICAgICAgICAgfCBSZWZlcmVuY2UgICAgICAgICB8DQogICB8IHByb3RvY29sICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgdHlwZXMgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IFVURjhTTVRQICAgIHwgRVNNVFAg d2l0aCBVVEY4U01UUGJpcyAgICAgICAgICB8IFtSRkNYWFhYXSAgICAgICAgIHwNCiAgIHwgVVRG OFNNVFBBICAgfCBFU01UUCB3aXRoIFVURjhTTVRQYmlzIGFuZCBTTVRQIHwgW1JGQzQ5NTRdICAg ICAgICAgfA0KICAgfCAgICAgICAgICAgICB8IEFVVEggICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCBbUkZDWFhYWF0gICAgICAgICB8DQogICB8IFVURjhTTVRQUyAgIHwgRVNNVFAgd2l0aCBV VEY4U01UUGJpcyBhbmQgICAgICB8IFtSRkMzMjA3XSAgICAgICAgIHwNCiAgIHwgICAgICAgICAg ICAgfCBTVEFSVFRMUyAgICAgICAgICAgICAgICAgICAgICAgIHwgW1JGQ1hYWFhdICAgICAgICAg fA0KICAgfCBVVEY4U01UUFNBICB8IEVTTVRQIHdpdGggVVRGOFNNVFBiaXMgYW5kIGJvdGggfCBb UkZDMzIwN10gICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgU1RBUlRUTFMgYW5kIFNNVFAg QVVUSCAgICAgICAgICB8IFtSRkM0OTU0XSAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgW1JGQ1hYWFhdICAgICAgICAgfA0KICAg DQpJbiBEZWMuIDIwMTEsIHRoZSBXRyBjaGFpciBhbm5vdW5jZWQgdGhhdCAiDQpVbmxlc3MgdGhl cmUgYXJlIHN1Y2ggb2JqZWN0aW9ucywgdGhlIG5ldyBrZXl3b3JkIG5vdGlmaWNhdGlvbiB3aWxs IGJlIGZvcndhcmRlZCB0byB0aGUgUkZDIEVkaXRvciBhbmQgSUFOQS4iDQpodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ltYS9JV0xncGZ5cng4MG1nZ1piVkVzQWlhRkk2aEUv IA0KDQpCZWZvcmUgdGhlIGZpbmFsIHZlcnNpb24gb2YgdGhpcyBkcmFmdCwgaWYgSSByZW1lbWJl ciBpdCBjb3JyZWN0bHksIHdoZW4gd2UgYXNrZWQgd2hldGhlciB3ZSBzaG91bGQgY2hhbmdlICJV VEY4U01UUCIgIlVURjhTTVRQQSIgIlVURjhTTVRQUyIuLi4gdG8gc29tZXRoaW5nIGVsc2UsIHNv bWUgV0cgbWVtYmVycyByZWNvbW1lbmRlZCB0aGF0IHdlIGp1c3Qga2VlcCBpdC4NCg0KSSB0cmll ZCB0byBkaWcgdGhlIG1lc3NhZ2UgaW4gdGhlIG1haWxpbmcgbGlzdCwgYnV0IEkgY2FuIG5vdCBm aW5kIGl0Lg0KDQpBbnlvbmUgcmVtZW1iZXIgaXQ/IGRpc2N1c3Npb24gaW4gdGhlIG1haWxpbmcg bGlzdCBvciB0aGUgbWVldGluZz8NCg0KDQpCZXN0IFJlZ2FyZHMNCkppYW5rYW5nIFlhbw0KDQoN CkZyb206IEpvaG4gQyBLbGVuc2luDQpEYXRlOiAyMDIxLTAxLTA0IDEzOjM1DQpUbzogaW1hOyBZ QU8gSmlhbmthbmcNCkNDOiBhcnMtYWRzDQpTdWJqZWN0OiBSYXRoZXIgc2VyaW91cyBidWcgaW4g UkZDIDY1MzENClRvZGF5J3MgTmV3IFllYXIncyBiYWQgbmV3cy4uLg0KDQpNYW55IG9mIHlvdSB3 aG8gd2VyZSBhcm91bmQgaW4gMjAxMSBhbmQgZWFybHkgMjAxMiB3aWxsIHJlY2FsbA0KdGhhdCB0 aGVyZSB3YXMgYSBmYWlybHkgZXh0ZW5kZWQgZGlzY3Vzc2lvbiBpbiB0aGUgRUFJIFdHIGFib3V0 DQp3aGV0aGVyIHRvIHJldGFpbiB0aGUgIlVURjhTTVRQIiBrZXl3b3JkIHVzZWQgaW4gdGhlDQpl eHBlcmltZW50YWwgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sIChkb2N1bWVudGVkIGluIFJGQyA1 MzM2KQ0KYW5kIHRoZSBzdGFuZGFyZHMgdHJhY2sgdmVyc2lvbiAoZG9jdW1lbnRlZCBpbiBSRkMg NjUzMSkuDQpQcmltYXJpbHkgYmVjYXVzZSB0aGUgc2VtYW50aWNzIG9mIHRoZSBleHRlbnNpb24g YW5kIHNldmVyYWwNCnRoaW5ncyBzdXJyb3VuZGluZyBpdCBoYWQgY2hhbmdlZCBhbmQgc3lzdGVt cyAoYW5kIHRob3NlIHRyeWluZw0KdG8gZGVidWcgbWFpbCB0cmFuc2FjdGlvbnMpIHNob3VsZCBr bm93IGV4YWN0bHkgd2hhdCB0aGV5IGFyZQ0KYXNraW5nIGZvciBhbmQgYWdyZWVpbmcgdG8sIHRo ZSBXRyBjb25jbHVkZWQgdGhhdCB0aGUgZXh0ZW5zaW9uDQprZXl3b3JkIHNob3VsZCBiZSBjaGFu Z2VkLCB0aGUgV0cgZGVjaWRlZCB0byBjaGFuZ2UgdGhlDQpleHRlbnNpb24gbmFtZSwgdWx0aW1h dGVseSB0byBTTVRQVVRGOC4gICBQdXQgZGlmZmVyZW50bHksDQpiZWNhdXNlIHRoZSBFeHBlcmlt ZW50YWwgYW5kIFN0YW5kYXJkcyBUcmFjayB2ZXJzaW9ucyByZWFsbHkNCndlcmUgaW5jb21wYXRp YmxlIGluIGltcG9ydGFudCB3YXlzLCB0aGUgaW50ZW50IHdhcyB0byBtYWtlIGl0DQpjbGVhciB0 aGF0IHRoZSBwcm90b2NvbHMgd2VyZSBkaWZmZXJlbnQuIA0KDQpCZWNhdXNlIHRoZSByZWFzb24g Zm9yIGNoYW5naW5nIHRoZSBleHRlbnNpb24ga2V5d29yZCB3YXMgdG8NCm1ha2UgaXQgY2xlYXIg d2hldGhlciB0aGUgRXhwZXJpbWVudGFsIG9yIFN0YW5kYXJkcyBUcmFjaw0KcHJvdG9jb2xzIHdl cmUgYmVpbmcgdXNlZCwgd2hpbGUgaXQgd2FzLCBhcyBmYXIgYXMgSSBjYW4NCnJlbWVtYmVyIG9y IHRlbGwgZnJvbSBtaW51dGVzIG9yIG15IG5vdGVzLCBuZXZlciBleHBsaWNpdGx5DQpkaXNjdXNz ZWQsIEkgYmVsaWV2ZSB0aGUgY2xlYXIgaW50ZW50IG9mIHRoZSBXRyB3YXMgdGhhdCB0aGUNCmtl eXdvcmRzIHVzZWQgaW4gdGhlIFdJVEggY2xhdXNlIGluIHRpbWUgc3RhbXAgdHJhY2UgZmllbGRz IHVzZQ0KdGhlIG5ldyBrZXl3b3JkIGZvcm0uICANCg0KRm9yIHdoYXRldmVyIHJlYXNvbiwgdGhh dCBkaWRuJ3QgaGFwcGVuLiAgQUZBSUNULCBvdGhlciB0aGFuDQpiZWluZyBhc3NpZ25lZCBhIHNl cGFyYXRlIHNlY3Rpb24gbnVtYmVyIGFuZCBpbnRyb2R1Y3RvcnkNCnNlbnRlbmNlLCBrZXl3b3Jk cyBpbiB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBkaXNjdXNzaW9uIG9mIHRoZQ0KV0lUSCBjbGF1 c2Ugd2VyZSBjYXJyaWVkIGZvcndhcmQgdW5jaGFuZ2VkIGZyb20gUkZDIDUzMzYgZXZlbg0KdGhv dWdoIFNNVFBVVEY4IHJlcGxhY2VkIFVURjhTTVRQIGluIHRoZSBEZXNjcmlwdGlvbnMsIGxlYWRp bmcNCnRvIHRoZSBwb3RlbnRpYWwgZm9yIGV4YWN0bHkgdGhlICJ3aGljaCBwcm90b2NvbCBpcyBy ZWFsbHkgaW4NCnVzZT8iIHF1ZXN0aW9uIHRoYXQgdGhlIFdHIGludGVuZGVkIHRvIGF2b2lkLg0K DQpJIHdhbnQgdG8gc3RyZXNzIHRoYXQgdGhlIGF1dGhvcnMgYXJlIG5vdCB0byBibGFtZSBmb3Ig dGhpcy4NCkV2ZXJ5IG9uZSBvZiB1cyB3aG8gd2FzIGludm9sdmVkIHdpdGggdGhlIFdHIGR1cmlu ZyBXRyBhbmQgSUVURg0KTGFzdCBDYWxsIG9uIHdoYXQgYmVjYXVzZSBSRkMgNjUzMSBpcyBlcXVh bGx5IHJlc3BvbnNpYmxlIGZvcg0Kbm90IHNwb3R0aW5nIHRoZSBwcm9ibGVtIGFuZCBpbnNpc3Rp bmcgdGhhdCB0aGUgV0cgZGlzY3VzcyBpdC4NClRoZSBxdWVzdGlvbiBpcyB3aGF0IHdlIGRvIGFi b3V0IGl0IHRvZGF5Lg0KDQo+RnJvbSBhIHByb2NlZHVyYWwgc3RhbmRwb2ludCwgUkZDIDY1MzEg aXMgKG9ubHkpIGEgUHJvcG9zZWQNClN0YW5kYXJkIGFuZCByZXZpc2luZyBpdCB0byBjb3JyZWN0 IGEgY2xlYXIgbWlzdGFrZSwgZXNwZWNpYWxseQ0KYSBtaXN0YWtlIHRoYXQgaXMgaW5jb25zaXN0 ZW50IHdpdGggdGhlIFdHJ3MgcmVhc29uaW5nIGluIDIwMTEsDQppcyBlbnRpcmVseSBpbiBvcmRl ci4gICBGcm9tIGEgbW9yZSBwcmFnbWF0aWMgc3RhbmRwb2ludCwgdGhlDQpxdWVzdGlvbnMgYXJl IHdoZXRoZXIgbWFraW5nIHRoZSBjaGFuZ2UgYXQgdGhpcyBwb2ludCB3b3VsZCBiZQ0Kd29ydGgg dGhlIGRpc3J1cHRpb24uICBJZiB3ZSBhcmUgYWJzb2x1dGVseSBwb3NpdGl2ZSB0aGF0IHRoZXJl DQphcmUgbm8gaW1wbGVtZW50YXRpb25zIG9mIFJGQyA1MzM2IGxlZnQgaW4gdGhlIHdpbGQsIHRo ZSBhbnN3ZXINCmlzIHByb2JhYmx5IG5vdCBldmVuIHRob3NlIGl0IG1lYW5zIGFjY2VwdGluZyBs b25nLXRlcm0NCmNvbmZ1c2lvbiBiZXR3ZWVuIHRoZSBleHRlbnNpb24ga2V5d29yZCBhbmQgdGhl IFdJVEggdmFsdWVzIChhDQpwcm9ibGVtIHRoYXQsIEFGQUlLLCB3ZSBkb24ndCBoYXZlIHdpdGgg YW55IG90aGVyIFNNVFANCmV4dGVuc2lvbi4gICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2UgZXhw ZWN0IG1vcmUgU01UUFVURjgNCmltcGxlbWVudGF0aW9ucyBpbiB0aGUgZnV0dXJlIHRoYW4gd2Ug aGF2ZSB0b2RheSBvciBpZiB0aGVyZQ0KbWlnaHQgc3RpbGwgYmUgaW1wbGVtZW50YXRpb25zIG9m IHRoZSBFeHBlcmltZW50YWwgcHJvdG9jb2wgb3V0DQp0aGVyZSwgY2hhbmdpbmcvY29ycmVjdGlu ZyB0aGUgV0lUSCBrZXl3b3JkcyBub3cgd291bGQgcHJvYmFibHkNCnJlZHVjZSBjb25mdXNpb24g aW4gdGhlIGxvbmcgdGVybXMgYW5kIHdvdWxkIGJlIGxlc3MgcGFpbmZ1bCBub3cNCnRoYW4gbGF0 ZXIuDQoNCk1ha2luZyB0aGUgY2hhbmdlLCBzaG91bGQgd2UgZGVjaWRlIHRvIGRvIHNvLCB3b3Vs ZCByZXF1aXJlIGENCm9uZSAoc3Vic3RhbnRpdmUpIHBhZ2UgUkZDIGV4cGxhaW5pbmcgdGhlIFdH J3MgaW50ZW50IGFuZA0KcmVxdWVzdGluZyBJQU5BIGNoYW5nZSB0aGUga2V5d29yZHMuICBJIHN1 cHBvc2UsIGFzIGEgZ3VpbHR5DQpwYXJ0eSBmb3Igbm90IGNhdGNoaW5nIHRoaXMgYSBkZWNhZGUg YWdvLCBJJ20gd2lsbGluZyB0byB3cml0ZQ0KYW4gcG9zdCBpdC4gIElmIHdlIGRlY2lkZSB0byBu b3RlIG1ha2UgdGhlIGNoYW5nZSwgSSBtaWdodA0KZ2VuZXJhdGUgc3VjaCBhbiBJLUQgYW55d2F5 IGp1c3QgdG8gaGF2ZSBhIHNsaWdodGx5IG1vcmUNCnBlcm1hbmVudC8gYXZhaWxhYmxlIHJlY29y ZCB0aGFuIHRoaXMgbm90ZSB0aGF0IHRoZSBkZWNpc2lvbiB3YXMNCmV4cGxpY2l0Lg0KDQpXaGF0 IGRvIHBlb3BsZSB0aGluaz8NCg0KICAgIGpvaG4= ------=_001_NextPart235750070600_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello John and all,
 
 
     Happy New Year to all!
     The final version of the draft is https://= tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16=20
     which keeps the following text:
 
   |  WITH       =
| Description                     | Reference         |
   | protocol    |                                 |                   |
   | types       |                                 |                   |
   +-------------+---------------------------------+-------------------+
   | UTF8SMTP    | ESMTP with UTF8SMTPbis          | [RFCXXXX]         |
   | UTF8SMTPA   | ESMTP with UTF8SMTPbis and SMTP | [RFC4954]         |
   |             | AUTH                            | [RFCXXXX]         |
   | UTF8SMTPS   | ESMTP with UTF8SMTPbis and      | [RFC3207]         |
   |             | STARTTLS                        | [RFCXXXX]         |
   | UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207]         |
   |             | STARTTLS and SMTP AUTH          | [RFC4954]         |
   |             |                                 | [RFCXXXX]         |
  
In Dec. 2011, the WG chair announced that "
Unless there are such objec=
tions, the new keyword notification will be forwarded to the RFC Editor an=
d IANA."
https://mailarchive.ietf.org/arch/msg/ima/IWLgpfyrx80mggZbVEsAiaFI6h= E/=20
 
Before the final version of this draft, if I remember it correctly, w= hen we=20 asked whether we should change "UTF8SMTP" "UTF8SMTPA" "UTF8SMTPS"... to=20 something else, some WG members recommended that we just keep it.
 
I tried to dig the message in the mailing list, but I can not find=20 it.
 
Anyone remember it? discussion in the mailing list or the meeting?
 
 
Best Regards
Jiankang Yao
 
 
Date: 2021-01-04 13:35
To: ima; YAO Jiankang
CC: ars-ads
Subject: Rather serious bug in RFC 6531
Today's New Year's bad news...
 
Many of you who were around in 201= 1 and early 2012 will recall
that there was a fairly extended discus= sion in the EAI WG about
whether to retain the "UTF8SMTP" keyword&nbs= p;used in the
experimental versions of the protocol (docum= ented in RFC 5336)
and the standards track version (documented&= nbsp;in RFC 6531).
Primarily because the semantics of the = extension and several
things surrounding it had changed and s= ystems (and those trying
to debug mail transactions) should know = ;exactly what they are
asking for and agreeing to, the WG = ;concluded that the extension
keyword should be changed, the WG decid= ed to change the
extension name, ultimately to SMTPUTF8. &nbs= p; Put differently,
because the Experimental and Standards Track=  versions really
were incompatible in important ways, the&nbs= p;intent was to make it
clear that the protocols were different.&nbs= p;
 
Because the reason for changing the ext= ension keyword was to
make it clear whether the Experimental = or Standards Track
protocols were being used, while it was= , as far as I can
remember or tell from minutes or my&nbs= p;notes, never explicitly
discussed, I believe the clear intent o= f the WG was that the
keywords used in the WITH clause in&nbs= p;time stamp trace fields use
the new keyword form.  
 
For whatever reason, that didn't happen.&nbs= p; AFAICT, other than
being assigned a separate section number&nbs= p;and introductory
sentence, keywords in the IANA Consideration= s discussion of the
WITH clause were carried forward unchanged&n= bsp;from RFC 5336 even
though SMTPUTF8 replaced UTF8SMTP in the&nbs= p;Descriptions, leading
to the potential for exactly the "which=  protocol is really in
use?" question that the WG intended to&= nbsp;avoid.
 
I want to stress that the authors = are not to blame for this.
Every one of us who was involved w= ith the WG during WG and IETF
Last Call on what because RFC 6531 = ;is equally responsible for
not spotting the problem and insisting = that the WG discuss it.
The question is what we do about i= t today.
 
>From a procedural standpoint, RFC 6531&n= bsp;is (only) a Proposed
Standard and revising it to correct a&n= bsp;clear mistake, especially
a mistake that is inconsistent with the=  WG's reasoning in 2011,
is entirely in order.   From a&nbs= p;more pragmatic standpoint, the
questions are whether making the change = ;at this point would be
worth the disruption.  If we are a= bsolutely positive that there
are no implementations of RFC 5336 left=  in the wild, the answer
is probably not even those it means&nbs= p;accepting long-term
confusion between the extension keyword and&= nbsp;the WITH values (a
problem that, AFAIK, we don't have with=  any other SMTP
extension.   On the other hand, if=  we expect more SMTPUTF8
implementations in the future than we h= ave today or if there
might still be implementations of the E= xperimental protocol out
there, changing/correcting the WITH keywords = ;now would probably
reduce confusion in the long terms and&= nbsp;would be less painful now
than later.
 
Making the change, should we decide to&= nbsp;do so, would require a
one (substantive) page RFC explaining the&nb= sp;WG's intent and
requesting IANA change the keywords.  I=  suppose, as a guilty
party for not catching this a decade&nb= sp;ago, I'm willing to write
an post it.  If we decide to = note make the change, I might
generate such an I-D anyway just to&nbs= p;have a slightly more
permanent/ available record than this note&n= bsp;that the decision was
explicit.
 
What do people think?
 
    john
 
 
 
 
 
------=_001_NextPart235750070600_=------ From nobody Mon Jan 4 02:46:19 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0860D3A0B92 for ; Mon, 4 Jan 2021 02:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 yr1zjG9gNcCc for ; Mon, 4 Jan 2021 02:46:16 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9560A3A0B8F for ; Mon, 4 Jan 2021 02:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1609757174; d=isode.com; s=june2016; i=@isode.com; bh=rOLVvwCrwKKloKorc6/uHeYWwQ5s4JRG6lgK94boqSw=; 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=CP5o1GWcTwDbDAvig819RG/FX2MUqJmGPATBcDUjHGDAurg0DDH0HfoI1MDu/mNE+7zrav 8LUM/m08e04QP5MQkx8W8TtVf7A9RK2GOLhnr1eCi5cUUr80L57R/IQ752cvXB/GcwqM7p Vn071LCqQngHt/TS/pwixlyedR0F8Lw=; Received: from [172.27.255.49] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jan 2021 10:46:14 +0000 To: Jiankang , John C Klensin , ima Cc: ars-ads References: <71B5C1132B119F30CC7A5A7A@PSB> <202101041715352454377@cnnic.cn> From: Alexey Melnikov Message-ID: Date: Mon, 4 Jan 2021 10:46:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-Reply-To: <202101041715352454377@cnnic.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8C24214222AFF76E9D59626C" Content-Language: en-GB Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 10:46:18 -0000 --------------8C24214222AFF76E9D59626C Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Hi all, On 04/01/2021 09:16, Jiankang Yao wrote: > Hello John and all, > =C2=A0=C2=A0=C2=A0=C2=A0 Happy New Year to all! > =C2=A0=C2=A0=C2=A0=C2=A0 The final version of the draft is=20 > https://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16=20 > > =C2=A0=C2=A0=C2=A0=C2=A0 which keeps the following text: > | WITH | Description | Reference | > | protocol | | | > | types | | | > +-------------+---------------------------------+-------------------+ > | UTF8SMTP | ESMTP with UTF8SMTPbis | [RFCXXXX] | > | UTF8SMTPA | ESMTP with UTF8SMTPbis and SMTP | [RFC4954 ] | > | | AUTH | [RFCXXXX] | > | UTF8SMTPS | ESMTP with UTF8SMTPbis and | [RFC3207 ] | > | | STARTTLS | [RFCXXXX] | > | UTF8SMTPSA | ESMTP with UTF8SMTPbis and both | [RFC3207 ] | > | | STARTTLS and SMTP AUTH | [RFC4954 ] | > | | | [RFCXXXX] | > In Dec. 2011, the WG chair announced that " > Unless there are such objections, the new keyword notification will be for= warded to the RFC Editor and IANA." > https://mailarchive.ietf.org/arch/msg/ima/IWLgpfyrx80mggZbVEsAiaFI6hE/=20 > > Before the final version of this draft, if I remember it correctly,=20 > when we asked whether we should change "UTF8SMTP" "UTF8SMTPA"=20 > "UTF8SMTPS"... to something else, some WG members recommended that we=20 > just keep it. My personal opinion is that the likelyhood of older versions being=20 implemented is low and my desire to minimize number of different WITH=20 keywords is high, so I think the decision in RFC 6531 not to change=20 keywords is the right one. Best Regards, Alexey > I tried to dig the message in the mailing list, but I can not find it. > Anyone remember it? discussion in the mailing list or the meeting? > Best Regards > Jiankang Yao > *From:* John C Klensin > *Date:*=C2=A02021-01-04=C2=A013:35 > *To:* ima ; YAO Jiankang > *CC:* ars-ads > *Subject:*=C2=A0Rather serious bug in RFC 6531 > Today's=C2=A0New=C2=A0Year's=C2=A0bad=C2=A0news... > Many=C2=A0of=C2=A0you=C2=A0who=C2=A0were=C2=A0around=C2=A0in=C2=A02011=C2= =A0and=C2=A0early=C2=A02012=C2=A0will=C2=A0recall > that=C2=A0there=C2=A0was=C2=A0a=C2=A0fairly=C2=A0extended=C2=A0discussion= =C2=A0in=C2=A0the=C2=A0EAI=C2=A0WG=C2=A0about > whether=C2=A0to=C2=A0retain=C2=A0the=C2=A0"UTF8SMTP"=C2=A0keyword=C2=A0use= d=C2=A0in=C2=A0the > experimental=C2=A0versions=C2=A0of=C2=A0the=C2=A0protocol=C2=A0(documented= =C2=A0in=C2=A0RFC=C2=A05336) > and=C2=A0the=C2=A0standards=C2=A0track=C2=A0version=C2=A0(documented=C2=A0= in=C2=A0RFC=C2=A06531). > Primarily=C2=A0because=C2=A0the=C2=A0semantics=C2=A0of=C2=A0the=C2=A0exten= sion=C2=A0and=C2=A0several > things=C2=A0surrounding=C2=A0it=C2=A0had=C2=A0changed=C2=A0and=C2=A0system= s=C2=A0(and=C2=A0those=C2=A0trying > to=C2=A0debug=C2=A0mail=C2=A0transactions)=C2=A0should=C2=A0know=C2=A0exac= tly=C2=A0what=C2=A0they=C2=A0are > asking=C2=A0for=C2=A0and=C2=A0agreeing=C2=A0to,=C2=A0the=C2=A0WG=C2=A0conc= luded=C2=A0that=C2=A0the=C2=A0extension > keyword=C2=A0should=C2=A0be=C2=A0changed,=C2=A0the=C2=A0WG=C2=A0decided=C2= =A0to=C2=A0change=C2=A0the > extension=C2=A0name,=C2=A0ultimately=C2=A0to=C2=A0SMTPUTF8.=C2=A0=C2=A0=C2= =A0Put=C2=A0differently, > because=C2=A0the=C2=A0Experimental=C2=A0and=C2=A0Standards=C2=A0Track=C2= =A0versions=C2=A0really > were=C2=A0incompatible=C2=A0in=C2=A0important=C2=A0ways,=C2=A0the=C2=A0int= ent=C2=A0was=C2=A0to=C2=A0make=C2=A0it > clear=C2=A0that=C2=A0the=C2=A0protocols=C2=A0were=C2=A0different. > Because=C2=A0the=C2=A0reason=C2=A0for=C2=A0changing=C2=A0the=C2=A0extensio= n=C2=A0keyword=C2=A0was=C2=A0to > make=C2=A0it=C2=A0clear=C2=A0whether=C2=A0the=C2=A0Experimental=C2=A0or=C2= =A0Standards=C2=A0Track > protocols=C2=A0were=C2=A0being=C2=A0used,=C2=A0while=C2=A0it=C2=A0was,=C2= =A0as=C2=A0far=C2=A0as=C2=A0I=C2=A0can > remember=C2=A0or=C2=A0tell=C2=A0from=C2=A0minutes=C2=A0or=C2=A0my=C2=A0not= es,=C2=A0never=C2=A0explicitly > discussed,=C2=A0I=C2=A0believe=C2=A0the=C2=A0clear=C2=A0intent=C2=A0of=C2= =A0the=C2=A0WG=C2=A0was=C2=A0that=C2=A0the > keywords=C2=A0used=C2=A0in=C2=A0the=C2=A0WITH=C2=A0clause=C2=A0in=C2=A0tim= e=C2=A0stamp=C2=A0trace=C2=A0fields=C2=A0use > the=C2=A0new=C2=A0keyword=C2=A0form. > For=C2=A0whatever=C2=A0reason,=C2=A0that=C2=A0didn't=C2=A0happen.=C2=A0=C2= =A0AFAICT,=C2=A0other=C2=A0than > being=C2=A0assigned=C2=A0a=C2=A0separate=C2=A0section=C2=A0number=C2=A0and= =C2=A0introductory > sentence,=C2=A0keywords=C2=A0in=C2=A0the=C2=A0IANA=C2=A0Considerations=C2= =A0discussion=C2=A0of=C2=A0the > WITH=C2=A0clause=C2=A0were=C2=A0carried=C2=A0forward=C2=A0unchanged=C2=A0f= rom=C2=A0RFC=C2=A05336=C2=A0even > though=C2=A0SMTPUTF8=C2=A0replaced=C2=A0UTF8SMTP=C2=A0in=C2=A0the=C2=A0Des= criptions,=C2=A0leading > to=C2=A0the=C2=A0potential=C2=A0for=C2=A0exactly=C2=A0the=C2=A0"which=C2= =A0protocol=C2=A0is=C2=A0really=C2=A0in > use?"=C2=A0question=C2=A0that=C2=A0the=C2=A0WG=C2=A0intended=C2=A0to=C2=A0= avoid. > I=C2=A0want=C2=A0to=C2=A0stress=C2=A0that=C2=A0the=C2=A0authors=C2=A0are= =C2=A0not=C2=A0to=C2=A0blame=C2=A0for=C2=A0this. > Every=C2=A0one=C2=A0of=C2=A0us=C2=A0who=C2=A0was=C2=A0involved=C2=A0with= =C2=A0the=C2=A0WG=C2=A0during=C2=A0WG=C2=A0and=C2=A0IETF > Last=C2=A0Call=C2=A0on=C2=A0what=C2=A0because=C2=A0RFC=C2=A06531=C2=A0is= =C2=A0equally=C2=A0responsible=C2=A0for > not=C2=A0spotting=C2=A0the=C2=A0problem=C2=A0and=C2=A0insisting=C2=A0that= =C2=A0the=C2=A0WG=C2=A0discuss=C2=A0it. > The=C2=A0question=C2=A0is=C2=A0what=C2=A0we=C2=A0do=C2=A0about=C2=A0it=C2= =A0today. > >From=C2=A0a=C2=A0procedural=C2=A0standpoint,=C2=A0RFC=C2=A06531=C2=A0is= =C2=A0(only)=C2=A0a=C2=A0Proposed > Standard=C2=A0and=C2=A0revising=C2=A0it=C2=A0to=C2=A0correct=C2=A0a=C2=A0c= lear=C2=A0mistake,=C2=A0especially > a=C2=A0mistake=C2=A0that=C2=A0is=C2=A0inconsistent=C2=A0with=C2=A0the=C2= =A0WG's=C2=A0reasoning=C2=A0in=C2=A02011, > is=C2=A0entirely=C2=A0in=C2=A0order.=C2=A0=C2=A0=C2=A0From=C2=A0a=C2=A0mor= e=C2=A0pragmatic=C2=A0standpoint,=C2=A0the > questions=C2=A0are=C2=A0whether=C2=A0making=C2=A0the=C2=A0change=C2=A0at= =C2=A0this=C2=A0point=C2=A0would=C2=A0be > worth=C2=A0the=C2=A0disruption.=C2=A0=C2=A0If=C2=A0we=C2=A0are=C2=A0absolu= tely=C2=A0positive=C2=A0that=C2=A0there > are=C2=A0no=C2=A0implementations=C2=A0of=C2=A0RFC=C2=A05336=C2=A0left=C2= =A0in=C2=A0the=C2=A0wild,=C2=A0the=C2=A0answer > is=C2=A0probably=C2=A0not=C2=A0even=C2=A0those=C2=A0it=C2=A0means=C2=A0acc= epting=C2=A0long-term > confusion=C2=A0between=C2=A0the=C2=A0extension=C2=A0keyword=C2=A0and=C2=A0= the=C2=A0WITH=C2=A0values=C2=A0(a > problem=C2=A0that,=C2=A0AFAIK,=C2=A0we=C2=A0don't=C2=A0have=C2=A0with=C2= =A0any=C2=A0other=C2=A0SMTP > extension.=C2=A0=C2=A0=C2=A0On=C2=A0the=C2=A0other=C2=A0hand,=C2=A0if=C2= =A0we=C2=A0expect=C2=A0more=C2=A0SMTPUTF8 > implementations=C2=A0in=C2=A0the=C2=A0future=C2=A0than=C2=A0we=C2=A0have= =C2=A0today=C2=A0or=C2=A0if=C2=A0there > might=C2=A0still=C2=A0be=C2=A0implementations=C2=A0of=C2=A0the=C2=A0Experi= mental=C2=A0protocol=C2=A0out > there,=C2=A0changing/correcting=C2=A0the=C2=A0WITH=C2=A0keywords=C2=A0now= =C2=A0would=C2=A0probably > reduce=C2=A0confusion=C2=A0in=C2=A0the=C2=A0long=C2=A0terms=C2=A0and=C2=A0= would=C2=A0be=C2=A0less=C2=A0painful=C2=A0now > than=C2=A0later. > Making=C2=A0the=C2=A0change,=C2=A0should=C2=A0we=C2=A0decide=C2=A0to=C2=A0= do=C2=A0so,=C2=A0would=C2=A0require=C2=A0a > one=C2=A0(substantive)=C2=A0page=C2=A0RFC=C2=A0explaining=C2=A0the=C2=A0WG= 's=C2=A0intent=C2=A0and > requesting=C2=A0IANA=C2=A0change=C2=A0the=C2=A0keywords.=C2=A0=C2=A0I=C2= =A0suppose,=C2=A0as=C2=A0a=C2=A0guilty > party=C2=A0for=C2=A0not=C2=A0catching=C2=A0this=C2=A0a=C2=A0decade=C2=A0ag= o,=C2=A0I'm=C2=A0willing=C2=A0to=C2=A0write > an=C2=A0post=C2=A0it.=C2=A0=C2=A0If=C2=A0we=C2=A0decide=C2=A0to=C2=A0note= =C2=A0make=C2=A0the=C2=A0change,=C2=A0I=C2=A0might > generate=C2=A0such=C2=A0an=C2=A0I-D=C2=A0anyway=C2=A0just=C2=A0to=C2=A0hav= e=C2=A0a=C2=A0slightly=C2=A0more > permanent/=C2=A0available=C2=A0record=C2=A0than=C2=A0this=C2=A0note=C2=A0t= hat=C2=A0the=C2=A0decision=C2=A0was > explicit. > What=C2=A0do=C2=A0people=C2=A0think? > =C2=A0=C2=A0=C2=A0=C2=A0john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima --------------8C24214222AFF76E9D59626C Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable

Hi all,


On 04/01/2021 09:16, Jiankang Yao wrote:
Hello John and all,
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 Happy New Year to all!
=C2=A0=C2=A0=C2=A0=C2=A0 The final version of the draft is https://tools.ietf.org/html/draft-ietf-ea= i-rfc5336bis-16
=C2=A0=C2=A0=C2=A0=C2=A0 which keeps the following text:
=C2=A0
   |  WITH       | Descr=
iption                     | Reference         |
   | protocol    |                                 |                   |
   | types       |                                 |                   |
   +-------------+---------------------------------+-------------------+
   | UTF8SMTP    | ESMTP with UTF8SMTPbis          | [RFCXXXX]         |
   | UTF8SMTPA   | ESMTP with UTF8SMTPbis and SMTP | [RFC4954]         |
   |             | AUTH                            | [RFCXXXX]         |
   | UTF8SMTPS   | ESMTP with UTF8SMTPbis and      | [RFC3207]         |
   |             | STARTTLS                        | [RFCXXXX]         |
   | UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207]         |
   |             | STARTTLS and SMTP AUTH          | [RFC4954]         |
   |             |                                 | [RFCXXXX]         |
=C2=A0=C2=A0
In Dec. 2011, the WG chair announced that " 
Unless ther=
e are such objections, the new keyword notification will be forwarded to the=
 RFC Editor and IANA."
=C2=A0
Before the final version of this draft, if I remember it correctly, when we asked whether we should change "UTF8SMTP" "UTF8SMTPA" "UTF8SMTPS"... to something else, some WG members recommended that we just keep it.


My personal opinion is that the likelyhood of older versions being implemented is low and my desire to minimize number of different WITH keywords is high, so I think the decision in RFC 6531 not to change keywords is the right one.


Best Regards,

Alexey


=C2=A0
I tried to dig the message in the mailing list, but I can not find it.
=C2=A0
Anyone remember it? discussion in the mailing list or the meeting?
=C2=A0
=C2=A0
Best Regards
Jiankang Yao
=C2=A0
=C2=A0
From:=C2=A0John C Klensin
Date:=C2=A02021-01-04=C2=A013:35
To:=C2=A0ima; YAO Jiankang
CC:=C2=A0ars-ads
Subject:=C2=A0Rather serious bug in RFC 6531
Today's=C2=A0New=C2=A0Year's=C2=A0bad=C2=A0news...
=C2=A0
Many=C2=A0of=C2=A0you=C2=A0who=C2=A0were=C2=A0around=C2=A0in=C2= =A02011=C2=A0and=C2=A0early=C2=A02012=C2=A0will=C2=A0recall
that=C2=A0there=C2=A0was=C2=A0a=C2=A0fairly=C2=A0extended=C2=A0= discussion=C2=A0in=C2=A0the=C2=A0EAI=C2=A0WG=C2=A0about
whether=C2=A0to=C2=A0retain=C2=A0the=C2=A0"UTF8SMTP"=C2=A0keywo= rd=C2=A0used=C2=A0in=C2=A0the
experimental=C2=A0versions=C2=A0of=C2=A0the=C2=A0protocol=C2=A0= (documented=C2=A0in=C2=A0RFC=C2=A05336)
and=C2=A0the=C2=A0standards=C2=A0track=C2=A0version=C2=A0(docum= ented=C2=A0in=C2=A0RFC=C2=A06531).
Primarily=C2=A0because=C2=A0the=C2=A0semantics=C2=A0of=C2=A0the= =C2=A0extension=C2=A0and=C2=A0several
things=C2=A0surrounding=C2=A0it=C2=A0had=C2=A0changed=C2=A0and= =C2=A0systems=C2=A0(and=C2=A0those=C2=A0trying
to=C2=A0debug=C2=A0mail=C2=A0transactions)=C2=A0should=C2=A0kno= w=C2=A0exactly=C2=A0what=C2=A0they=C2=A0are
asking=C2=A0for=C2=A0and=C2=A0agreeing=C2=A0to,=C2=A0the=C2=A0W= G=C2=A0concluded=C2=A0that=C2=A0the=C2=A0extension
keyword=C2=A0should=C2=A0be=C2=A0changed,=C2=A0the=C2=A0WG=C2= =A0decided=C2=A0to=C2=A0change=C2=A0the
extension=C2=A0name,=C2=A0ultimately=C2=A0to=C2=A0SMTPUTF8.=C2= =A0=C2=A0=C2=A0Put=C2=A0differently,
because=C2=A0the=C2=A0Experimental=C2=A0and=C2=A0Standards=C2= =A0Track=C2=A0versions=C2=A0really
were=C2=A0incompatible=C2=A0in=C2=A0important=C2=A0ways,=C2=A0t= he=C2=A0intent=C2=A0was=C2=A0to=C2=A0make=C2=A0it
clear=C2=A0that=C2=A0the=C2=A0protocols=C2=A0were=C2=A0differen= t.=C2=A0
=C2=A0
Because=C2=A0the=C2=A0reason=C2=A0for=C2=A0changing=C2=A0the=C2= =A0extension=C2=A0keyword=C2=A0was=C2=A0to
make=C2=A0it=C2=A0clear=C2=A0whether=C2=A0the=C2=A0Experimental= =C2=A0or=C2=A0Standards=C2=A0Track
protocols=C2=A0were=C2=A0being=C2=A0used,=C2=A0while=C2=A0it=C2= =A0was,=C2=A0as=C2=A0far=C2=A0as=C2=A0I=C2=A0can
remember=C2=A0or=C2=A0tell=C2=A0from=C2=A0minutes=C2=A0or=C2=A0= my=C2=A0notes,=C2=A0never=C2=A0explicitly
discussed,=C2=A0I=C2=A0believe=C2=A0the=C2=A0clear=C2=A0intent= =C2=A0of=C2=A0the=C2=A0WG=C2=A0was=C2=A0that=C2=A0the
keywords=C2=A0used=C2=A0in=C2=A0the=C2=A0WITH=C2=A0clause=C2=A0= in=C2=A0time=C2=A0stamp=C2=A0trace=C2=A0fields=C2=A0use
the=C2=A0new=C2=A0keyword=C2=A0form.=C2=A0=C2=A0
=C2=A0
For=C2=A0whatever=C2=A0reason,=C2=A0that=C2=A0didn't=C2=A0happe= n.=C2=A0=C2=A0AFAICT,=C2=A0other=C2=A0than
being=C2=A0assigned=C2=A0a=C2=A0separate=C2=A0section=C2=A0numb= er=C2=A0and=C2=A0introductory
sentence,=C2=A0keywords=C2=A0in=C2=A0the=C2=A0IANA=C2=A0Conside= rations=C2=A0discussion=C2=A0of=C2=A0the
WITH=C2=A0clause=C2=A0were=C2=A0carried=C2=A0forward=C2=A0uncha= nged=C2=A0from=C2=A0RFC=C2=A05336=C2=A0even
though=C2=A0SMTPUTF8=C2=A0replaced=C2=A0UTF8SMTP=C2=A0in=C2=A0t= he=C2=A0Descriptions,=C2=A0leading
to=C2=A0the=C2=A0potential=C2=A0for=C2=A0exactly=C2=A0the=C2=A0= "which=C2=A0protocol=C2=A0is=C2=A0really=C2=A0in
use?"=C2=A0question=C2=A0that=C2=A0the=C2=A0WG=C2=A0intended=C2= =A0to=C2=A0avoid.
=C2=A0
I=C2=A0want=C2=A0to=C2=A0stress=C2=A0that=C2=A0the=C2=A0authors= =C2=A0are=C2=A0not=C2=A0to=C2=A0blame=C2=A0for=C2=A0this.
Every=C2=A0one=C2=A0of=C2=A0us=C2=A0who=C2=A0was=C2=A0involved= =C2=A0with=C2=A0the=C2=A0WG=C2=A0during=C2=A0WG=C2=A0and=C2=A0IETF
Last=C2=A0Call=C2=A0on=C2=A0what=C2=A0because=C2=A0RFC=C2=A0653= 1=C2=A0is=C2=A0equally=C2=A0responsible=C2=A0for
not=C2=A0spotting=C2=A0the=C2=A0problem=C2=A0and=C2=A0insisting= =C2=A0that=C2=A0the=C2=A0WG=C2=A0discuss=C2=A0it.
The=C2=A0question=C2=A0is=C2=A0what=C2=A0we=C2=A0do=C2=A0about= =C2=A0it=C2=A0today.
=C2=A0
>From=C2=A0a=C2=A0procedural=C2=A0standpoint,=C2=A0RFC=C2=A0= 6531=C2=A0is=C2=A0(only)=C2=A0a=C2=A0Proposed
Standard=C2=A0and=C2=A0revising=C2=A0it=C2=A0to=C2=A0correct=C2= =A0a=C2=A0clear=C2=A0mistake,=C2=A0especially
a=C2=A0mistake=C2=A0that=C2=A0is=C2=A0inconsistent=C2=A0with=C2= =A0the=C2=A0WG's=C2=A0reasoning=C2=A0in=C2=A02011,
is=C2=A0entirely=C2=A0in=C2=A0order.=C2=A0=C2=A0=C2=A0From=C2= =A0a=C2=A0more=C2=A0pragmatic=C2=A0standpoint,=C2=A0the
questions=C2=A0are=C2=A0whether=C2=A0making=C2=A0the=C2=A0chang= e=C2=A0at=C2=A0this=C2=A0point=C2=A0would=C2=A0be
worth=C2=A0the=C2=A0disruption.=C2=A0=C2=A0If=C2=A0we=C2=A0are= =C2=A0absolutely=C2=A0positive=C2=A0that=C2=A0there
are=C2=A0no=C2=A0implementations=C2=A0of=C2=A0RFC=C2=A05336=C2= =A0left=C2=A0in=C2=A0the=C2=A0wild,=C2=A0the=C2=A0answer
is=C2=A0probably=C2=A0not=C2=A0even=C2=A0those=C2=A0it=C2=A0mea= ns=C2=A0accepting=C2=A0long-term
confusion=C2=A0between=C2=A0the=C2=A0extension=C2=A0keyword=C2= =A0and=C2=A0the=C2=A0WITH=C2=A0values=C2=A0(a
problem=C2=A0that,=C2=A0AFAIK,=C2=A0we=C2=A0don't=C2=A0have=C2= =A0with=C2=A0any=C2=A0other=C2=A0SMTP
extension.=C2=A0=C2=A0=C2=A0On=C2=A0the=C2=A0other=C2=A0hand,= =C2=A0if=C2=A0we=C2=A0expect=C2=A0more=C2=A0SMTPUTF8
implementations=C2=A0in=C2=A0the=C2=A0future=C2=A0than=C2=A0we= =C2=A0have=C2=A0today=C2=A0or=C2=A0if=C2=A0there
might=C2=A0still=C2=A0be=C2=A0implementations=C2=A0of=C2=A0the= =C2=A0Experimental=C2=A0protocol=C2=A0out
there,=C2=A0changing/correcting=C2=A0the=C2=A0WITH=C2=A0keyword= s=C2=A0now=C2=A0would=C2=A0probably
reduce=C2=A0confusion=C2=A0in=C2=A0the=C2=A0long=C2=A0terms=C2= =A0and=C2=A0would=C2=A0be=C2=A0less=C2=A0painful=C2=A0now
than=C2=A0later.
=C2=A0
Making=C2=A0the=C2=A0change,=C2=A0should=C2=A0we=C2=A0decide=C2= =A0to=C2=A0do=C2=A0so,=C2=A0would=C2=A0require=C2=A0a
one=C2=A0(substantive)=C2=A0page=C2=A0RFC=C2=A0explaining=C2=A0= the=C2=A0WG's=C2=A0intent=C2=A0and
requesting=C2=A0IANA=C2=A0change=C2=A0the=C2=A0keywords.=C2=A0= =C2=A0I=C2=A0suppose,=C2=A0as=C2=A0a=C2=A0guilty
party=C2=A0for=C2=A0not=C2=A0catching=C2=A0this=C2=A0a=C2=A0dec= ade=C2=A0ago,=C2=A0I'm=C2=A0willing=C2=A0to=C2=A0write
an=C2=A0post=C2=A0it.=C2=A0=C2=A0If=C2=A0we=C2=A0decide=C2=A0to= =C2=A0note=C2=A0make=C2=A0the=C2=A0change,=C2=A0I=C2=A0might
generate=C2=A0such=C2=A0an=C2=A0I-D=C2=A0anyway=C2=A0just=C2=A0= to=C2=A0have=C2=A0a=C2=A0slightly=C2=A0more
permanent/=C2=A0available=C2=A0record=C2=A0than=C2=A0this=C2=A0= note=C2=A0that=C2=A0the=C2=A0decision=C2=A0was
explicit.
=C2=A0
What=C2=A0do=C2=A0people=C2=A0think?
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0john
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0

_______________________________=
________________
IMA mailing list
IMA@ietf.=
org
https://www.ietf.org/mailman/listinfo/ima
--------------8C24214222AFF76E9D59626C-- From nobody Mon Jan 4 09:32:55 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7593A0EAD for ; Mon, 4 Jan 2021 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=nm75HlpM; dkim=pass (2048-bit key) header.d=taugh.com header.b=ENE+0Er7 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 0dweouK587Kz for ; Mon, 4 Jan 2021 09:32:52 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97D63A0EAC for ; Mon, 4 Jan 2021 09:32:52 -0800 (PST) Received: (qmail 59665 invoked from network); 4 Jan 2021 17:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e90f.5ff35141.k2101; bh=/PEwjJTnRhEOFCpJQJH6vbmrU3/RWXvaWPFPLb71Ha8=; b=nm75HlpM3qgrgWeD0JHSb8s8B2/UH6+EXv0spWDbASpoTXTrEBn6aV2vIJrQFPgiSsb9pU18xkdH+c5BI1oJxbriawbx9HBFc6g6pGZ1ZtKtHSm8Xudn7WmB7S9OK/2c2NHvb0Hx/ktg6qJFowFOEHWwlJIFtSUnA0P1HUSBfXMLWxFblz2ZjsV3ymxJG3XoBh+wzRbLet9H3v5TW8OFWFTZPObmZ69486j7Sxt5EZ9txP+lRx1HVRF3f7uBjnjOHVHLRM5JG04EkfIeWEZNtHoe15n8mFfmvYJW85tHP53HcnUnMDKg78RY8HfkhciLhirfE22rAsr7OTD3r5yPXw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=e90f.5ff35141.k2101; bh=/PEwjJTnRhEOFCpJQJH6vbmrU3/RWXvaWPFPLb71Ha8=; b=ENE+0Er7lrJ7rBpHv6lt6ZwSM4d1ApZ7k3NFup/ID+AZtngGSSQqXD3brhm14QCK/mTDroaK6ybZm4xSQgl/n9KmvABLnVPB8gpQAd6bk8Qn2HiMMnZXaeiI/eyKrIWibsvBLpoFFcmmV8HhtCIMeeU7XweQByZeO8HW9QULMZy41HvsHi9JHdA1yiiTkxNAQbppEM6ST8e5xoQOHtTutYD1BlR10Tr1IxsuDSk+yHvKwGGLIE7B4bfbe4BY9Ph6ugYkOv8UbSFB20iB4/6DnThhBZL6xrUQH7WuVK9h8BLR/0GtdES67dEOJuM98hwrSrOHR0Vk2AUKFlj0Cq5DcQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Jan 2021 17:32:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 51F3154CD6FA; Mon, 4 Jan 2021 12:32:48 -0500 (EST) Date: 4 Jan 2021 12:32:48 -0500 Message-Id: <20210104173248.51F3154CD6FA@ary.qy> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 17:32:54 -0000 In article you write: >My personal opinion is that the likelyhood of older versions being >implemented is low and my desire to minimize number of different WITH >keywords is high, so I think the decision in RFC 6531 not to change >keywords is the right one. Having just done some EAI compliance tests for the UASG, I can report that all the systems that have any EAI support at all do what the RFC says. The SMTP keyword is SMTPUTF8, and the WITH clause is UTF8SMTP. (Well, except for Microsoft whose WITH clauses are wrong with or without EAI.) At this point I am not aware of any live implmentations of the experimental version other than in IMAP at Coremail, and that one is sufficiently broken that I doubt anyone is using it. I agree we should leave it alone. R's, John From nobody Mon Jan 4 10:26:29 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35B53A0EF6 for ; Mon, 4 Jan 2021 10:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wUzh-REIH5jo for ; Mon, 4 Jan 2021 10:26:25 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA7B3A0EF2 for ; Mon, 4 Jan 2021 10:26:25 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwUYi-000IXI-Ec; Mon, 04 Jan 2021 13:26:24 -0500 Date: Mon, 04 Jan 2021 13:26:18 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: In-Reply-To: <20210104173248.51F3154CD6FA@ary.qy> References: <20210104173248.51F3154CD6FA@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 18:26:28 -0000 --On Monday, January 4, 2021 12:32 -0500 John Levine wrote: > In article > you write: >> My personal opinion is that the likelyhood of older versions >> being implemented is low and my desire to minimize number of >> different WITH keywords is high, so I think the decision in >> RFC 6531 not to change keywords is the right one. > > Having just done some EAI compliance tests for the UASG, I can > report that all the systems that have any EAI support at all > do what the RFC says. The SMTP keyword is SMTPUTF8, and the > WITH clause is UTF8SMTP. (Well, except for Microsoft whose > WITH clauses are wrong with or without EAI.) This is good to know, but since it would be really strange for an implementation to ignore the spec, make its own guesses as to what the keywords should be, and then use them, it would be surprising if it were otherwise. The only case we might see would be one using the old SMTP extension keyword of UTF8SMTP, which would indicate the experimental protocol. Good news that we are not seeing that and we can only hope that all implementations sending out SMTPUTF8 are actually conforming to the Proposed Standard protocol in area where they are different. Our of curiosity, are/were your tests sensitive enough to tell the difference? As you hint, Microsoft has significant history of qualifying for "really strange", going back at least to the implementations of Exchange Server in the early 1990s whose version of SMTP used an X.400 design and terminology. > At this point I am not aware of any live implmentations of the > experimental version other than in IMAP at Coremail, and that > one is sufficiently broken that I doubt anyone is using it. > > I agree we should leave it alone. I think it is important that we discuss this and make an explicit decision. The big argument for making a change is that people (notably yourself included) get confused as refer to the SMTP extension and associated changes as "UTF8SMTP". That is much better than referring to them as "EAI", but having three terminology options where we should have one is unhealthy and confusing to those who are not insiders and even some of us. On the other hand, if the specified WITH keywords are widely deployed (as they seem to be) and we don't expect to see a significant number of new implementation in the near or mid-term future (I haven't noticed a significant rate of growth recently, but maybe others have), inflicting a change on everyone as the result of a mistake we didn't catch a decade ago does not seem wise or appropriate. best, john From nobody Mon Jan 4 11:01:23 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1E3A0FC4 for ; Mon, 4 Jan 2021 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=oHs2X7iV; dkim=pass (2048-bit key) header.d=taugh.com header.b=Vjcdi/Fy 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 A16QSBJVRVGb for ; Mon, 4 Jan 2021 11:01:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52933A0EA9 for ; Mon, 4 Jan 2021 11:01:19 -0800 (PST) Received: (qmail 81527 invoked from network); 4 Jan 2021 19:01:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=13e75.5ff365fd.k2101; bh=42IDcwsZ+6B1dpFeK9J9qAxNlTyxMhb1Op7NPjbpm1s=; b=oHs2X7iV7M7Uz1zhuNDbkjeRzTe4Lj8QAEPOAntRhdKZoqeYcWZfZbDc487JxfHZz5bnHyQStmMa0DD1GcQVW0lXvPWf1tOvtf4p6U/OE+i3qbNydOH12bkuy53zl9FkoMYh9LoBgda9el0AW2al/nlwSM6ax8ucXoXNTUalBcVak98mavalS9g3qAcUHeLk5YxNibM8qNfbtVC02kcUYgrBSnk1RFDPNOM1ZT2FtPxk9fG+Z++c8iRKP2cBYHxytxI5qBkeBz7UKJAe+EeuckpupVSLozqFksnu86pyLeYJPO1bEKAVRvrV/ndBVVti1NbNnFb5b+yQbPP5T5WivQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=13e75.5ff365fd.k2101; bh=42IDcwsZ+6B1dpFeK9J9qAxNlTyxMhb1Op7NPjbpm1s=; b=Vjcdi/Fyr8dsZrXg48izwyP4oj1JrA+6+qjsj84NIZFQqOu7CBux3jSDTbM51TenSFmvHP38JMVvdV82b784XVhmy5V3M073dB5d906DYIUYZJgy9IM9v/cX8atvHZF37DTosK1CKssY5GxYvZIBp9OYEI9lJAnu5IvEbo5XMCGlED6VCsHFd5WNME2l8mSlUENxgDFszS7eymfWk453zW5ymq84oOox/Ke3nn3OJSdcoEfQrd1KZZ/eXZQ5qnYE8dW1VuIk4uVZsAUCoDy8+ljnwNAVm9brG3NGz4v+AVxUrXQ+s08PaqThzwxrwomNMEVxzDqM/M1WwJW+d/AVzA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Jan 2021 19:01:17 -0000 Received: by ary.qy (Postfix, from userid 501) id E5E2554DA072; Mon, 4 Jan 2021 14:01:16 -0500 (EST) Date: 4 Jan 2021 14:01:16 -0500 Message-Id: <20210104190116.E5E2554DA072@ary.qy> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 19:01:22 -0000 In article you write: >Our of curiosity, are/were your tests sensitive enough to tell >the difference? They weren't looking for nested addresses if that's what you're asking. But if they used UTF8SMTP as the keyword, they'd have failed and nobody did. I noticed the Coremail IMAP stuff because it was failing tests in odd ways. >As you hint, Microsoft has significant history of qualifying for >"really strange", going back at least to the implementations of >Exchange Server in the early 1990s whose version of SMTP used an >X.400 design and terminology. >> I agree we should leave it alone. > >I think it is important that we discuss this and make an >explicit decision. I think we should make an explicit decision to leave it alone. If we changed it I wouldn't expect implementations to change anytime soon. R's, John From nobody Mon Jan 4 13:32:15 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF75B3A1110 for ; Mon, 4 Jan 2021 13:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3UYUdhnO71iP for ; Mon, 4 Jan 2021 13:32:12 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029A23A1113 for ; Mon, 4 Jan 2021 13:32:11 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwXST-000JO4-OQ; Mon, 04 Jan 2021 16:32:09 -0500 Date: Mon, 04 Jan 2021 16:32:04 -0500 From: John C Klensin To: Jiankang , ima cc: ars-ads Message-ID: <2D073243C52FD2848BFEFD4C@PSB> In-Reply-To: <202101041715352454377@cnnic.cn> References: <71B5C1132B119F30CC7A5A7A@PSB> <202101041715352454377@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 21:32:14 -0000 --On Monday, January 4, 2021 17:16 +0800 Jiankang Yao wrote: > Hello John and all, > > > Happy New Year to all! > The final version of the draft is > https://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-16 > which keeps the following text: > > | WITH | Description | Reference > | | protocol | | > | | types | | > | > +-------------+---------------------------------+------------- > ------+ | UTF8SMTP | ESMTP with UTF8SMTPbis | > [RFCXXXX] | | UTF8SMTPA | ESMTP with UTF8SMTPbis > and SMTP | [RFC4954] | | | AUTH > | [RFCXXXX] | | UTF8SMTPS | ESMTP with > UTF8SMTPbis and | [RFC3207] | | | > STARTTLS | [RFCXXXX] | | > UTF8SMTPSA | ESMTP with UTF8SMTPbis and both | [RFC3207] > | | | STARTTLS and SMTP AUTH | > [RFC4954] | | | > | [RFCXXXX] | Yes, We know about that -- the same text is in the RFC and it would have been strange of impossible for it to have been changed (back) without anyone noticing. > In Dec. 2011, the WG chair announced that " > Unless there are such objections, the new keyword notification > will be forwarded to the RFC Editor and IANA." > https://mailarchive.ietf.org/arch/msg/ima/IWLgpfyrx80mggZbVEsA > iaFI6hE/ But that message, clearly talks about SMTPUTF8 only, not the WITH keywords. If anything, given the comparison toe the Experimental version of the spec, it could be taken as implying that the latter should be changed to match, but it certainly is not explicit about that. > Before the final version of this draft, if I remember it > correctly, when we asked whether we should change "UTF8SMTP" > "UTF8SMTPA" "UTF8SMTPS"... to something else, some WG members > recommended that we just keep it. My memory is fading, but I don't remember that discussion and certainly do not remember a consensus call on the subject. For the reasons given in the response I just sent to John Levine and noting that the WG even went out of its was to specify that the email internationalization protocols should be known as "SMTPUTF8" and not "EAI" [1], I cannot imagine that there would not be been strong objections to leave the old WITH keywords, Not only would the risk of confusion been clear, but the tradition with WITH keywords is that they are a close match to the particular protocol or extension in use. I certain believe you what you say that some people said "just keep it", but strongly suspect this just dropped through the cracks rather than being the result a specific question and WG consensus. > I tried to dig the message in the mailing list, but I can not > find it. > > Anyone remember it? discussion in the mailing list or the > meeting? See above. Not in any of my notes or on the design team list. It appears to me that, in chronological order, (i) the authors failed to identify this as a possibly significant issue and source of confusion and insist that the WG discuss it and make an explicit decision, (ii) the co-chairs didn't either, (iii) no one in the WG read the document carefully enough to identify the issue and insist that it be discussed and consensus reached (either while the document was under development or during WG Last Call), (iv) the WG co-chairs and document shepherd didn't notice before passing the document off to IESG, (v) no one studied it carefully enough during IETF Last Call either, (vi) IANA didn't notice or question it, but that isn't their job, especially when they were not asked to make a change, (vii) nor did the ADs at them time. No one of the groups of people in the above list are at fault; we all are. I don't know whether to interpret as bad news for the way document reviews are done in the IETF (and hence what "IETF Consensus" about a document means) or more evidence that the not enough people are paying serious attention to i18n issues to make the IETF a place to do competent work in that area. _However_, that would all be relevant to 6531 if we were a month or two post-publication and had then just noticed. At this point, eight years on, it no longer makes a difference and, IMO, the _only_ question is whether the disadvantages of the terminology difference and likely continuing terminology confusion outweigh the likely inconvenience and confusion of making a change. Alexey and John Levine prefer "no change". Speaking as an individual only, I think the argument is strongly for "no change" if we believe that almost every MTA that is going to implement SMTPUTF8 has already done so. If we believed that today's MTAs would be in the minority a decade from now (I don't think I believe that), then it might be worth making the change, dealing with the pain of transition, and waiting for current implementation to catch up (probably quite a while as John L predicts -- it is certainly not something I would prioritize if I were making those types of decisions). best, [1] For all the good that did. From nobody Tue Jan 5 05:29:08 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CE93A0EB3 for ; Tue, 5 Jan 2021 05:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 u-nWju2Akj6u for ; Tue, 5 Jan 2021 05:29:05 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8025B3A0EA7 for ; Tue, 5 Jan 2021 05:29:05 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTZ62SHPWG00DZ2Z@mauve.mrochek.com> for ima@ietf.org; Mon, 4 Jan 2021 09:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609782980; bh=xPQNuEDwZZnhxJb/PYSVEtjgQWRb1H1Khc0LL4pREiQ=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=rsAXb/63xO8BolB1V1iOomDqqUZoW77Y2vB3QYUTwMtVTGYkatLK/TSMdD46RbVCQ UGE8okMUIaJ9AyxvjBrAn6TkiETHN4k+D0DZg7Px/xq5DcQioHqeVmjbgS7vyBNtWi 4qldtlXJ8PHNskKiUiYZtBamuuEjglhYCi5M3KdA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTUUND7D1S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 4 Jan 2021 09:56:17 -0800 (PST) From: ned+ima@mrochek.com Cc: ima@ietf.org Message-id: <01RTZ62Q9PR6004QVR@mauve.mrochek.com> Date: Mon, 04 Jan 2021 09:53:15 -0800 (PST) In-reply-to: "Your message dated Mon, 04 Jan 2021 12:32:48 -0500" <20210104173248.51F3154CD6FA@ary.qy> References: <20210104173248.51F3154CD6FA@ary.qy> To: John Levine Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 13:29:07 -0000 > In article you write: > >My personal opinion is that the likelyhood of older versions being > >implemented is low and my desire to minimize number of different WITH > >keywords is high, so I think the decision in RFC 6531 not to change > >keywords is the right one. > Having just done some EAI compliance tests for the UASG, I can report > that all the systems that have any EAI support at all do what the RFC > says. The SMTP keyword is SMTPUTF8, and the WITH clause is UTF8SMTP. > (Well, except for Microsoft whose WITH clauses are wrong with or > without EAI.) FWIW, we generate the entire list of values: UTF8SMTP[A][S] and UTF8LMTP[A][S] as necessary. > At this point I am not aware of any live implmentations of the experimental > version other than in IMAP at Coremail, and that one is sufficiently broken > that I doubt anyone is using it. > I agree we should leave it alone. Yeah, this seems like the right choice to me as well. Ned From nobody Tue Jan 5 06:17:49 2021 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E173A0F46 for ; Tue, 5 Jan 2021 06:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=QbW4SnlU; dkim=pass (2048-bit key) header.d=taugh.com header.b=w28aHSBu 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 89muOwVzzRWH for ; Tue, 5 Jan 2021 06:17:44 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510DC3A0C6C for ; Tue, 5 Jan 2021 06:17:43 -0800 (PST) Received: (qmail 16372 invoked from network); 5 Jan 2021 14:17:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3ff0.5ff47506.k2101; i=johnl-iecc.com@submit.iecc.com; bh=5XUjQc8gItvQSH+lCAGzMu7OtDNwP35Bm3/Vlgr3Sgc=; b=QbW4SnlU6xWMQslgok4M3ACUMULgixlCiw+AxqyX522E88FJKPIO3VFF5EINSnHgn+p6LY6WlXpLr8KNGGUrmwuraOx5v02G4TBLZISxTPMSPQf69WI2jdkeuXfYo2vDjUNQgTPbmcYhcB2DgRfPpeSEdAtTdWYgcPbdGLUoDi1JdagbX7bGm5YH4fEoqBWqvDj+YLEBl9nI0QDtNEYJb5y4dkyKouEbkTZwlcxa1x48t24Wknp0WeEToeELlPb4qr1wXhlYTnVPBOHB4uSlAysF60eEMAk5EpOlryBv1jjhNIYFSddAXsj7PXCT0RPwqZlNVTcyK3DhIohBKidKjA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=3ff0.5ff47506.k2101; olt=johnl-iecc.com@submit.iecc.com; bh=5XUjQc8gItvQSH+lCAGzMu7OtDNwP35Bm3/Vlgr3Sgc=; b=w28aHSBunfCsrlDBs8d1Od6IFvxwRFhqouNHbuCc6sgEpk13WwPPyki3buuhGbfMbp7eEjsIas/SAz7YoCYwlm6sxVfklYYwF+vXybKLnCiLbDJ+djrklTvjumPIZsKNWZdt6qtf9gNfvUIMYmpU+Mg0xWkGpmE1zTXAkaZtJ1qp7EcnPSR4hXgjEim38zozuGnwh5zf60i+Wk7I/DZUORJnaWXMwS8Lx7fOZWzSV5z0oUrlOqLNUk8KSiio07f6bxJxHJqq+oSsrgsE++1L03fIyVE8tWl1Q8zLKsSfEBLWL+U5IY9OZh/m09oDk5NDWRRO7iV3hhaOkL5BE+GQug== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 05 Jan 2021 14:17:42 -0000 Date: 5 Jan 2021 09:17:42 -0500 Message-ID: From: "John R Levine" To: "Ned Freed" Cc: ima@ietf.org In-Reply-To: <01RTZ62Q9PR6004QVR@mauve.mrochek.com> References: <20210104173248.51F3154CD6FA@ary.qy> <01RTZ62Q9PR6004QVR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [EAI] Rather serious bug in RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 14:17:48 -0000 On Mon, 4 Jan 2021, Ned Freed wrote: >> Having just done some EAI compliance tests for the UASG, I can report >> that all the systems that have any EAI support at all do what the RFC >> says. The SMTP keyword is SMTPUTF8, and the WITH clause is UTF8SMTP. >> (Well, except for Microsoft whose WITH clauses are wrong with or >> without EAI.) > > FWIW, we generate the entire list of values: UTF8SMTP[A][S] and UTF8LMTP[A][S] > as necessary. I think everyone else does, too. The code is pretty simple. replace the prefix E with UTF8. There's a buglet in Courier where he forgets to remove the E, e.g., UTF8ESMTPS. I think I sent him the one-line fix. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly