Subject: [I18ndir] EAI: RFC 6531 Updates 5321?

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 28 Oct 2020 14:17:02 +0000

Folks, I have a question about i18n-related RFC updates that I hope you can shed some light on.

We recently had a suggestion from an IETF participant to add support for internationalized email addresses to EPP, which has a normative reference to RFC 5322 for email address syntax. It predates EAI, so there's nothing there to support internationalized local-parts. We're thinking about defining an EPP extension to add support, but the discussion on the regext WG list got me looking at the EAI RFCs and it made me wonder why they don't formally (in the Datatracker sense) update their predecessors. For example, Section 3.3 of RFC 6531 says that "RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters.  This document extends <Mailbox> to add support of non-ASCII characters", but there's nothing I can find in the Datatracker to note that 6531 updates 5321. 6531 *is* described as obsoleting 5336. Am I missing something? Shouldn't the Datatracker note the update relationships explicitly?

Scott

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2020 12:12:27 -0400

In article <[email-masked]> you write:
>characters", but there's nothing I can find in the Datatracker to note that 6531 updates 5321. 6531 *is* described as
>obsoleting 5336. Am I missing something? Shouldn't the Datatracker note the update relationships explicitly?

SMTP extensions don't update 5321 because they're optional. The only
RFC that has updated 5321 is 7504 which defines two new reply codes
that mail clients have to deal with.

In github-ese we might say that 6531 forks 5321 and 6532 forks 5322
but there's no good way to say that in an RFC.

R's,
John

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 30 Oct 2020 09:11:52 +0800

Hello Scott,

   According to my memory, when EAI WG discussed this issue, the WG intentionally said that 
"
 RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely
   in terms of ASCII characters.  This document extends <Mailbox> to add
   support of non-ASCII characters."

This means that it extends, but not updates.

RFC5321 is a base document. RFC6531 is one of its extension.

Best Regards

Jiankang Yao

From: Hollenbeck, Scott
Date: 2020-10-28 22:17
To: [email-masked]
Subject: [I18ndir] EAI: RFC 6531 Updates 5321?
Folks, I have a question about i18n-related RFC updates that I hope you can shed some light on.

Scott

-- 
I18ndir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i18ndir

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Oct 2020 12:34:37 +0000

Understood, and thanks (to John Levine, too).

Scott

From: I18ndir <[email-masked]> On Behalf Of Jiankang Yao
Sent: Thursday, October 29, 2020 9:12 PM
To: Hollenbeck, Scott <shollenbeck=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [I18ndir] EAI: RFC 6531 Updates 5321?

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello Scott,

"

 RFC 5321, Section 4.1.2<https://secure-web.cisco.com/1h1AbnNnUzxTw8IDVgN5FgVpgsd0CTn8STfGbLzwReymh3Kol6JjftpgPzoho9nhXGkUBWnhSJmov4m5bSxxfO0RTBHqU-n5C5kja6bi4DouC5BImW_LRtEdNcqoaunUtXQplmdypd3OPJvGc3frUJoU8Exq535tdBdDv_AEGufY6-bRFacelEZejQl8wFPzDn6lifrMDDoc4SSer4oi7iCi7Bc7f43EHM3DDikZ5kGlXyU0Xp8DGY1JeDaAqyD8MW4gUshzh5XrsczEzzMyGZpWalRUgX3-3-ItyOy24DV0/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5321%23section-4.1.2>, defines the syntax of a <Mailbox> entirely
   in terms of ASCII characters.  This document extends <Mailbox> to add
   support of non-ASCII characters.
"

Best Regards

  _____

Jiankang Yao

From: Hollenbeck, Scott<mailto:shollenbeck=[email-masked]>

Date: 2020-10-28 22:17

To: [email-masked]<mailto:[email-masked]>

Scott

--

I18ndir mailing list

[email-masked]<mailto:[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Oct 2020 12:15:39 -0400

Scott,

In the hope of improving understanding, while Jiankang is
correct and John mostly so (quibble below), the real issue goes
back to the circa 1992 agreement about and introduction of the
SMTP extension mechanism (see RFC 1425).  The underlying problem
is the need to maintain interoperability with a very broad
installed base, in that case by having a server advertise the
extensions it is willing to accept and then the client either
using zero or more of them or, more often, announcing that it is
about to use one or that a particular command should be
interpreted in the context of one.   If one of those extensions
were, instead, to update SMTP (whether 5321, 2821, or 821
itself), the effect would to declare all existing
implementations retroactively non-conforming.  This applies to
the need to use the extension mechanism for SMTPUTF8 because all
SMTP specs prior to 6531 (and 5335) have required all-ASCII
addresses.  Without a server explicitly saying what amounts to
"yes, I know about non-ASCII mailbox names and am able to handle
them", that server would be required to respond to such an
address in a MAIL or RCPT command with 
   500 syntax error - invalid character
(see Section 2.4 of 5321) or, in the specific case of mailbox
names, more likely something more like
   500 syntax error - WTF  [1]

That situation is by no means unique to non-ASCII characters in
mailbox names: the 8BITMIME extension is necessary to allow
non-ASCII characters in message bodies without encoding, the
BDAT one [RFC3030] is necessary to allow transmission of
non-textual, line-oriented, message content (again without
encoding).  While some extensions just provide additional
information, if most of the those so far had been allowed to
update SMTP, it would have been a source of immediate, and
probably disastrous, interoperability difficulties. 

I actually find it surprising that people in the EPP effort are
asking this question because they have a glaring example of a
different type of extension-type change for which special
measures were taken to avoid updating the base specification and
thereby obsoleting existing implementations and/or causing
serious interoperability problems and that is IDNA itself.  We
could have done IDNs by simply updating 1034 and 1035, declaring
that, henceforth, any label that had the high bit of an octet
set was UTF-8.  The only problem would have been that any
application or database that insisted on the "preferred syntax"
(which many people seem to think is required for any FQDN that
represents a "host name") would break, as would binary labels
[RFC2673] and any ad hoc IDN mechanisms that used a non-UTF-8
encoding (you will recall that some of those, notably one or two
using ISO 8859-1, were around and deployed before IDNA was
adopted).

In theory, one could have done IDNs in the DNS by flagging the
names somehow and then using an EDNS(0) mechanism to identify
what the strings were but that would have caused problems with
applications that use the DNS or allow user to see or enter
names rather than just carrying out DNS operations. 

There is actually text in the SMTPUTF8 documents (probably in
6530 but I don't remember) about the importance of having a
fallback plan to an all-ASCII if one is using non-ASCII
addresses outside restricted communities.  So, if there is a
perceived need to do this, let's talk about how and what
metadata and other supplemental information would be needed, but
5321 (or even 5321bis) are not part of the picture.  Of course,
this may raise the usual questions about how one finds all of
the relevant specs for a particular function, but that is a much
broader problem.  And there is the question of whether and to
what extent the SMTPUTF8 specs should be mentioned if and when
the EMAILCORE WG managed to make progress on the promised A/S --
we would welcome your participation in that discussion.

Finally, I've concerned about the analogy to "forks" unless that
term has come to encompass instant interoperability problems as
well as semi-orderly evolution that may branch out in different
directions.

best,
   john

[1] Hmm.  We don't have an extended status code for "WTF" or
even "non-ASCII character where it doesn't belong".  Maybe we
should.

--On Friday, October 30, 2020 12:34 +0000 "Hollenbeck, Scott"
<shollenbeck=[email-masked]> wrote:

> From: I18ndir <[email-masked]> On Behalf Of Jiankang
> Yao Sent: Thursday, October 29, 2020 9:12 PM
> To: Hollenbeck, Scott
> <shollenbeck=[email-masked]>; [email-masked]
> Caution: This email originated from outside the organization.
> Do not click links or open attachments unless you recognize
> the sender and know the content is safe.
> 
> Hello Scott,
> 
> 
> 
>  RFC 5321, Section
> 4.1.2<https://secure-web.cisco.com/1h1AbnNnUzxTw8IDVgN5FgVpgsd
> 0CTn8STfGbLzwReymh3Kol6JjftpgPzoho9nhXGkUBWnhSJmov4m5bSxxfO0RT
> BHqU-n5C5kja6bi4DouC5BImW_LRtEdNcqoaunUtXQplmdypd3OPJvGc3frUJo
> U8Exq535tdBdDv_AEGufY6-bRFacelEZejQl8wFPzDn6lifrMDDoc4SSer4oi7
> iCi7Bc7f43EHM3DDikZ5kGlXyU0Xp8DGY1JeDaAqyD8MW4gUshzh5XrsczEzzM
> yGZpWalRUgX3-3-ItyOy24DV0/https%3A%2F%2Ftools.ietf.org%2Fhtml%
> 2Frfc5321%23section-4.1.2>, defines the syntax of a <Mailbox>
> entirely    in terms of ASCII characters.  This document
> extends <Mailbox> to add    support of non-ASCII characters.
> "
> 
> 
> 
> From: Hollenbeck,
> Scott<mailto:shollenbeck=[email-masked]>
> 
> Date: 2020-10-28 22:17
> 
> We recently had a suggestion from an IETF participant to add
> support for internationalized email addresses to EPP, which
> has a normative reference to RFC 5322 for email address
> syntax. It predates EAI, so there's nothing there to support
> internationalized local-parts. We're thinking about defining
> an EPP extension to add support, but the discussion on the
> regext WG list got me looking at the EAI RFCs and it made me
> wonder why they don't formally (in the Datatracker sense)
> update their predecessors. For example, Section 3.3 of RFC
> 6531 says that "RFC 5321, Section 4.1.2, defines the syntax of
> a <Mailbox> entirely in terms of ASCII characters.  This
> document extends <Mailbox> to add support of non-ASCII
> characters", but there's nothing I can find in the Datatracker
> to note that 6531 updates 5321. 6531 *is* described as
> obsoleting 5336. Am I missing something? Shouldn't the
> Datatracker note the update relationships explicitly?
> 
> 
> 
> Scott
> 
> 
> 
> --
> 
> I18ndir mailing list
>

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2020 18:36:58 -0000

In article <305BD81F447F181D46E0C18A@PSB>,

>well as semi-orderly evolution that may branch out in different

It means both. Look at the many forks of markdown software that accept
not-quite compatible input formats, and the lack of any agreed way to
tell what markdown file expects to be processed with what software.

R's,
John

>   500 syntax error - WTF  [1]

I presume that stands for Wide Text Found.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly