[EAI] Rather serious bug in RFC 6531
John C Klensin <john-ietf@jck.com> Mon, 04 January 2021 05:35 UTC
Return-Path: <john-ietf@jck.com>
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 <ima@ietfa.amsl.com>; 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 <ima@ietfa.amsl.com>; 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 <ima@ietf.org>; 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 <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: ima@ietf.org, YAO Jiankang <yaojk@cnnic.cn>
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: <https://mailarchive.ietf.org/arch/msg/ima/kX5RFLqrdo-2H3ACpiRsbCi2bQU>
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\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=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
- [EAI] Rather serious bug in RFC 6531 John C Klensin
- Re: [EAI] Rather serious bug in RFC 6531 Jiankang Yao
- Re: [EAI] Rather serious bug in RFC 6531 Alexey Melnikov
- Re: [EAI] Rather serious bug in RFC 6531 John Levine
- Re: [EAI] Rather serious bug in RFC 6531 John C Klensin
- Re: [EAI] Rather serious bug in RFC 6531 John Levine
- Re: [EAI] Rather serious bug in RFC 6531 John C Klensin
- Re: [EAI] Rather serious bug in RFC 6531 John R Levine
- Re: [EAI] Rather serious bug in RFC 6531 ned+ima