Re: "International" email addresses [I18N-ACTION-374]

--On Thursday, November 27, 2014 08:58 +0100 Mark Davis ☕️
<mark@macchiato.com> wrote:

> I mostly about the 3 distinctions that Steven is drawing. It
> is certainly important to distinguish between "well-formed"
> (syntax) and "valid" (would actually work at runtime).
> However, the syntactic distinction could be tighter than what
> he suggests, but looser than
> https://html.spec.whatwg.org/multipage/forms.html#valid-e-mail
> -address, since the latter doesn't take into account either
> EAI or IDNA. I'd suggest something like the following:
>...

Folks,

Personally, I favor the types of restrictions Mark, Addison, and
others have suggested.  However, divergent specifications do no
one any good, especially when their effect is to prevent someone
from using an address as input in a web context that may be
valid and in use (even if, in your/our judgment unwise) in email
more generally.  So I strongly suggest:

(1) If these groups believe that the IETF specs are too
permissive or badly defined, put together a proposal and submit
it through the IETF process.

(2) Incorporate syntax rules and restrictions by reference to
the IETF specs only, thereby preventing both accidental
divergence and confusion about what the "real" rules are.

In addition to the obvious reasons for the above, there are some
email-specific issues involved in what the IETF documents
specified that may not be as familiar to this group.  For
example, Mark wrote...
 
>  * the above doesn't provide for quoted email addresses; the
> syntax would have to be enhanced to allow for those.

The decision to restrict quoted email addresses when the
SMTPUTF8 (aka "EAI") extensions where in use was discussed
carefully and at length.  The decision that was made was based
on circa 30 years of experience with the quoted forms causing
multiple problems as addresses were passed among systems with
different conventions.  The conclusion was that tightening the
rules a bit under the protection of the extension mechanism
would improve overall interoperability and not hurt anyone.  The
net result is that one can use both fancy quoting forms an
all-ASCII addresses or use non-ASCII addresses but not the
quoting forms.  It doesn't affect addresses unless name phrases
are used, but the SMTPUTF8 extensions also effectively prohibit
anything but (valid) UTF-8, even in encoded words [1], while,
historically, email with ASCII-only addresses and headers allows
encoded words in just about any "charset".   It seems to me
those restrictions are entirely in line with W3C and WHATWG
moves in other areas such as the Encoding spec.

    john

[1] Anyone participating in this discussion who doesn't know
_exactly_ what a "name phrase" and/or "encoded word" is in an
email context _really_ needs to go read the relevant specs.

Received on Thursday, 27 November 2014 08:34:26 UTC