draft-klensin-emailaddr-i18n-00

I have now read draft-klensin-emailaddr-i18n-00.  For convenience,
here's a link:

http://www.ietf.org/internet-drafts/draft-klensin-emailaddr-i18n-00.txt

I'm glad that John took the time to write this.  Whatever we end
up with, we'll have more confidence in it knowing that specific
alternatives were explored.

Here are my initial reactions.

The solution proposed in the draft presents itself as an MTA-level
extension to SMTP (RFC 2821).  But it implicitly assumes a corresponding
extension to the message header format (RFC 2822).  The messages carried
by ESMTP+I18N would not conform to RFC 2822, and existing MUAs could not
be expected to be able to reply to them.  I18N support is negotiated at
the MTA level, so that messages bounce if the recipient MTA does not
support the extension, but there is no negotiation at the MUA level;
the message will be successfully delivered, but replying might be
impossible.  Deployment of this approach would be critically dependent
on changes in both MTAs and MUAs.  Deployment of the IMAA approach could
proceed without changes to MTAs, and would be less critically dependent
on changes in MUAs, because old MUAs could still reply to messages
containing ACE forms, and users could still copy ACE forms between old
MUAs.

One case not addressed in the draft is a mailing list server that
supports the I18N extension.  Suppose some of the subscribers' MTAs
support it, and some don't.  When the list server receives a message
that depends on the extension (in the From or Cc field, for example),
what should happen?

> 2.2.1 Obtaining an Internationalized Email Address
>
> In general, users cannot create email accounts, or aliases controlling
> delivery of messages from external systems.

Yahoo Mail and similar services let you create a mailbox and choose
its name.  With IMAA, you could simply give it an ACE local part and
start taking advantage of IMAA without waiting for Yahoo to do anything.
Similarly, domain name registrars often provide mail hosting, and the
registrant could use an ACE local part without any IMA-awareness at the
hosting server.

> 2.3.1 MX diversion
>
> If the domain part of an email address is associated with several
> MX records and the mail is delivered to one of them that is not the
> best preference host, the receiving host is not required to use
> SMTP.  If, instead, it performs some gateway function, it may need to
> inspect or alter the local part to determine how to route and deliver
> the message.  If the local part were encoded in some fashion that
> prevented that inspection process, and the MTA was not aware that it
> needed to apply special techniques, mail delivery might well fail.

I don't think this problem is specific to non-primary mail exchangers,
or SMTP-to-other gateways.  The general problem is that the local
part structuring conventions used in a domain (by primary exchangers,
secondary exchangers, or gateways) could be incompatible with the IMAA
encoding.  For example, if the local parts in this domain use the letter
"x" as a delimiter, it won't be possible to use ACE local parts where
"x" appears as a result of the encoding, unless you upgrade the mail
exchangers to be IMA-aware.

Therefore, although IMAA is designed to allow the creation of
internationalized local parts without upgrades of MTAs, there could be
a few domains in which users will in fact have to wait for an upgrade
of their MTA before creating internationalized local parts.  This
inconvenience can arise only in domains that use letters or digits or
positions as delimiters.

The solution proposed in the draft would make users in all domains
(rather than just a few domains) wait for upgrades of their MTA before
they could create internationalized local parts.

> 2.4 Encoding the Whole Address String
>
> 2. Imposing a requirement that MTAs "understand" local-parts so that
>    they can be partially decoded as part of mail routing would seem to
>    defeat the main goal of encoding internationalized strings into a
>    compact ASCII-compatible form, i.e., to keep MTAs from needing to
>    understand the extended naming system

IMAA does not expect sending/relaying MTAs to understand local parts
at all.  IMAA encodes the whole local part at once, with no knowledge
of any local part structuring conventions; the encoding just happens
to have the convenient property that non-alphanumeric ASCII characters
are neither deleted nor inserted nor reordered.  Therefore, in any
domain whose existing local part structuring conventions use only
non-alphanumeric delimiters, the encoding will not interfere, and
users can immediately create ACE local parts without any upgrade to
the MTA.  Users who know the structuring conventions will be able to
parse/construct/manipulate non-ASCII local parts, while software will
parse/construct/manipulate ASCII local parts, and the two views will be
consistent.

Domains with local part structuring conventions that use letters,
digits, or positions as delimiters will have to upgrade their MTA before
internationalized local parts can be safely created in that domain, so
that both the software and the users will parse/construct/manipulate
non-ASCII local parts.

Perhaps that caveat deserves mention in the IMAA draft.

AMC