Re: [EAI] Rather serious bug in RFC 6531

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 04 January 2021 10:46 UTC

Return-Path: <alexey.melnikov@isode.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 0860D3A0B92 for <ima@ietfa.amsl.com>; 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 <ima@ietfa.amsl.com>; 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 <ima@ietf.org>; 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 <X=Lx9QAuQTgN@waldorf.isode.com>; Mon, 4 Jan 2021 10:46:14 +0000
To: Jiankang <yaojk@cnnic.cn>, John C Klensin <john-ietf@jck.com>, ima <ima@ietf.org>
Cc: ars-ads <ars-ads@ietf.org>
References: <71B5C1132B119F30CC7A5A7A@PSB> <202101041715352454377@cnnic.cn>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <f8ef03e7-59da-9753-9dad-4dc992b046eb@isode.com>
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: <https://mailarchive.ietf.org/arch/msg/ima/Vx7RoTk6grCYMefrVQCpoOU0a5s>
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 10:46:18 -0000

Hi all,


On 04/01/2021 09:16, 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 
> <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  <https://tools.ietf.org/html/rfc4954>]         |
>     |             | AUTH                            | [RFCXXXX]         |
>     | UTF8SMTPS   | ESMTP with UTF8SMTPbis and      | [RFC3207  <https://tools.ietf.org/html/rfc3207>]         |
>     |             | STARTTLS                        | [RFCXXXX]         |
>     | UTF8SMTPSA  | ESMTP with UTF8SMTPbis and both | [RFC3207  <https://tools.ietf.org/html/rfc3207>]         |
>     |             | STARTTLS and SMTP AUTH          | [RFC4954  <https://tools.ietf.org/html/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/ 
> <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.


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


> 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 <mailto:john-ietf@jck.com>
> *Date:* 2021-01-04 13:35
> *To:* ima <mailto:ima@ietf.org>; YAO Jiankang <mailto:yaojk@cnnic.cn>
> *CC:* ars-ads <mailto:ars-ads@ietf.org>
> *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
>
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima