Re: [EAI] Rather serious bug in RFC 6531

[Jiankang Yao <[e-mail]>]

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