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

[John C Klensin <[e-mail]>]

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=[e-mail]> wrote:

> Understood, and thanks (to John Levine, too).
> 
> 
> 
> Scott
> 
> 
> 
> From: I18ndir <[e-mail]> On Behalf Of Jiankang
> Yao Sent: Thursday, October 29, 2020 9:12 PM
> To: Hollenbeck, Scott
> <shollenbeck=[e-mail]>; [e-mail]
> 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,
> 
> 
> 
>    According to my memory, when EAI WG discussed this issue,
> the WG intentionally said that
> 
> "
> 
>  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.
> "
> 
> 
> 
> 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<mailto:shollenbeck=[e-mail]>
> 
> Date: 2020-10-28 22:17
> 
> To: [e-mail]<mailto:[e-mail]>
> 
> 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.
> 
> 
> 
> 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
> 
> [e-mail]<mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/i18ndir
> 
> 
>