Re: draft-klensin-emailaddr-i18n-00

John C Klensin <[email protected]> wrote:

> a delimiter-based approach that uses a non-ASCII delimiter would
> encounter the same problem as a string that used an ASCII letter as a
> delimiter rather than a conventional ASCII delimiter.

I wouldn't call it the same problem.  Consider an arbitrary non-ASCII
punctuation character, like U+00B7 (middle dot).  This character cannot
possibly have any special meaning in local parts in any domain, because
it has never been allowed in local parts in any domain.  After IMAA is
introduced, it will be possible for a domain to define (for the first
time ever) a special meaning for middle dot, but only if the domain's
MTA is IMA-aware.  That's hardly a surprising limitation.

Now consider an ASCII punctuation character, like U+002B (plus sign).
This character has a long history of having a special meaning in some
domains.  After IMAA is introduced, it will be possible to use non-ASCII
local parts in domains served by old MTAs (which might start happening
without any invitation from the administrator of the MTA).  But will
ASCII plus signs have the same special meaning in non-ASCII local parts
that they already have in ASCII local parts?  If IMAA isn't careful in
its encoding algorithm, the answer will be no.  Within a single domain,
plus signs will continue to have their historic effect in ASCII local
parts, and will have a different (null or chaotic) effect in non-ASCII
local parts.  Nothing like that can happen with middle dot.  This is a
different and worse problem.

With care, that problem can be avoided.  IMAA can ensure that the
encoding of text on one side of a protected ASCII character is not
influenced by the text on the other side of the protected character.
This guarantees that any protected characters that were already in use
as delimiters in ASCII local parts will have the same effect in both
ASCII and non-ASCII local parts.

> I really do think IDNA, or something _very_ like it, was the right
> approach for the DNS.  But it seems to me that the tradeoffs and
> considerations are different for email addresses

I would like to hear more details about how they are different.
Meanwhile, here are some ways in which they are similar:

Domain names are used in many protocols, so an incompatible change in
domain name syntax would entail changes to all those protocols, not
just DNS.  Similarly, mail addresses are used in several protocols.  If
message header syntax is extended and SMTP is extended to negotiate
support for extended mail headers, don't POP and IMAP need analogous
negotiation extensions?  And news headers and NNTP?  And mailto URIs
and the protocols that carry them (HTML, HTTP)?  And whatever else I've
forgotten or don't know about...

If IDNs were downright inaccessible (not merely ugly) to existing
protocols, interfaces, software, etc, then people would be quite
relucant to create IDNs (which could have worse implications than just
slow deployment; if the activation energy exceeds some threshold, the
reaction will not even start).  Similarly, if IMAs are inaccessible to
existing MTAs, MUAs, mailing list software, news readers, web browsers,
etc, then people will be quite reluctant to create them.

> the two approaches are not necessarily incompatible.
>
> Technically speaking, the transport infrastructure could accommodate
> specially-encoded local parts as well as UTF-8 ones, just as it could
> recognize and accommodate punycode domain names as well as UTF-8 ones.

Yes, the same is true of IDNs.  Any protocol that currently uses ASCII
domain names could be extended to support non-ASCII domain names
directly.  For example, IRIs are being defined as an extension of URIs,
and IRIs will allow a non-ASCII host name where URIs allow only an ASCII
host name.

That is not the only difference between IRIs and URIs; other fields are
also being extended to allow non-ASCII.  If an extended message header
format is to be defined, I would expect it to allow non-ASCII in many
places (like display-name and unstructured), not just addresses.

It is possible to define an extended DNS protocol that supports
non-ASCII domain names directly.  This can be done at any time, or
never.  There was no need to hold up IDNA while the details of non-ASCII
DNS were worked out.  Similarly, there is no need to hold up IMAA while
the details of non-ASCII message headers are worked out.

AMC