Subject: [EAI] SMTP replies containing non-ASCII text (was: Re: Consensus result on Issue #1 - Parameter on MAIL FROM)

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2011 10:39:52 -0500

(personal opinion, although one based on considerable
experience) except for the last paragraph)

A few people have commented about use of a parameter to enable
reply messages that contain non-ASCII characters.  We have been
down the path that leads in that direction multiple times.   RFC
5321 and its predecessors make it very clear that message or
address-specific text is needed only for the replies to VRFY and
EXPN and the little-used and problematic 251 and 551 responses
to RCPT (see Section 3.4 of RFC 5321).  Over the years, the
community has considered and rejected multiple "reply language"
proposals.  In its earlier life, this WG looked at the
possibility of non-ASCII reply text and decided to not include
it in the model.

In each case, the primary reason has been the same as the
primary reason for not internationalizing header field names
(and a specific case of a design principle that goes back to the
early ARPANET).   If we use a common language (and, to the
extent possible, standardized text) in field names and replies,
it is relatively easy for user agents to translate from that
language to whatever is appropriate locally.   If we put
material in arbitrary languages (even if all in UTF-8) on the
wire, then every user agent that wants to accept or report
localized text has to understand every language that might be
encountered.  The latter is an interoperability disaster.   At
least as serious, since the language (not just the CCS and
encoding) have to be known in order to do translations, one
needs a way to transmit and process language information, not
just charset (CCS and encoding) information.  In case it isn't
obvious, neither address information nor free text (as in
Subject header fields or display names) need language
information because there is no real expectation of translation.
That is not the case for replies.

VRFY and EXPN are necessarily dealt with separately.  If we
really need non-ASCII support for addresses in 251 and 551
replies, then let's confine ourselves to the bracketed addresses
in those replies and not start encouraging arbitrary text in
arbitrary languages 

My strong personal preference is that we not reopen the issue of
internationalized replies on the wire.  If we must do so, let's
keep it separate from other issues to the extent possible rather
than assuming that an EAI-capable client can accept and process
non-ASCII replies (even restricted to Unicode in UTF-8) and that
it is reasonable for servers to send them.  

As a co-chair who has been charged by the WG to make this
process go as quickly as possible, I should add that reopening
the issue and getting into a long discussion of non-ASCII reply
text is inconsistent with anything resembling speed.

---

From: John Levine <[email-masked]>
Date: 2 Feb 2011 17:28:13 -0000

>internationalized replies on the wire.

As the author of an MTA that's been known to respond

  550 Message Accepted

I entirely agree with this sentiment.

R's,
John