Re: [EAI] Rather serious bug in RFC 6531

John C Klensin <> Mon, 04 January 2021 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF75B3A1110 for <>; Mon, 4 Jan 2021 13:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3UYUdhnO71iP for <>; Mon, 4 Jan 2021 13:32:12 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 029A23A1113 for <>; Mon, 4 Jan 2021 13:32:11 -0800 (PST)
Received: from [] (helo=PSB) by 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: <>
References: <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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [EAI] Rather serious bug in RFC 6531
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
> 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."
> 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

_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).


[1] For all the good that did.