Re: [EAI] Rather serious bug in RFC 6531

Jiankang Yao <yaojk@cnnic.cn> Mon, 04 January 2021 09:17 UTC

Return-Path: <yaojk@cnnic.cn>
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 <ima@ietfa.amsl.com>; 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 <ima@ietfa.amsl.com>; 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 <ima@ietf.org>; 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" <yaojk@cnnic.cn>
To: "John C Klensin" <john-ietf@jck.com>, ima <ima@ietf.org>
Cc: ars-ads <ars-ads@ietf.org>
Reply-To: Jiankang <yaojk@cnnic.cn>
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: <https://mailarchive.ietf.org/arch/msg/ima/x6vsXiw55tzAIjSUp40KBpEzcSM>
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\)" <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 09:17:06 -0000

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]         |
   
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/IWLgpfyrx80mggZbVEsAiaFI6hE/ 

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.

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: 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 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