Comments on draft-klensin-emailaddr-i18n-00

I have read John's draft-klensin-emailaddr-i18n-00 and I am glad
to get one draft where we start by looking at extending the
current Internet protocols from ASCII to UCS, instead of just
encoding all non-ASCII into ASCII without fixing the protocol.

As Adam have pointed out there are many things that can be discussed
and problems that can be seen, by doing it this way instead of the
IMAA way. But the IMAA and IDNA way does also introduce many problems.

I think this way is the right one. Yes, both MUAs and MTAs need to
be upgraded. But without that, the use of non-ASCII e-mail addresses
will be so ugly that nobody will use them. Just like MIME was not
very popular before enough clients could handle it.
Nor will IDNA be very good before DNS clients and servers are upgraded.
And it would have been no problem to require upgraded DNS servers
to support non-ASCII in domain names, to get them to be used.
Those who want them would have forced the upgrade.

The draft have many open questions - I recommend that we go for full
internationalisation of all headers so all headers are in UTF-8,
and MIME-encoded headers are forbidden. This would greatly simplify
handling in MTAs/MUAs and gives a clear signal to everybody that
the ASCII only world is going away.
Local part, domain names, subject etc. must all be in UTF-8.
Allowing some parts in punycode or some other encoded form
will just add a lot of unnecessary complexity.

To make handling of UTF-8 text, the standard should require
Unicode normalisation form C (NFC). This does not destroy
any information while making this much simpler for the
implementor.

For e-mail addresses we probably should recommend that only
the smallest code point of the same character to be used.
Otherwise some may use, for example, the wide form of some 
latin characters which could not be expected to match
most addresses with latin characters as they will be using
the standard width code point.

When this draft is ready we can look at a way to downgrade
to legacy ASCII e-mail. But as we here require all MTAs/MUAs
handling international mailboxes to be upgraded, we can
use a simpler downgrading to ASCII than IMAA as we only need
the ASCII would so see international local part as an
opaque ASCII string.


   Dan