John,
JCK> If one is going to consider internationalization of email
JCK> addresses in a way that permits them to move through the mail
JCK> protocol in some traditional Unicode encoding (e.g., UTF-8),
JCK> then
...then we get to repeat the mime/esmtp debates all over again. After all,
why should we even try to learn anything from 10 years of experience. (And
no, John, I'm not directing my comment at you.)
To be specific: I am not suggesting that pure utf-8 is a bad goal -- although
the fact that utf-8 is, itself, a condensed representation of unicode should
strike folks as a just a tad ironic, with respect to these discussions.
Rather, I suggest that it be a _separate_ goal from near-term support of an
edge-only enhancement for Unicode support, the same as we did for mime and
IDN.
We already have that support for domain names. That only leaves local-part.
It's fine to pursue a separate path for long-term 8-bit purity. I'm sure we
will achieve it much sooner for addresses than we have for content.
JCK> Again, the goal is that this should be natural for the user,
JCK> using the user's script (or the script of the recipient), both
JCK> in protocol transactions and in the case of "My email address is
JCK> xx(_at_)yy(_dot_)"
The business card representation of an email address is the classic example of
IETF work that very much _does_ directly involve the user interface. However
we already dealt with this issue for non-ascii domain names. We do not need
to rehash this issue yet again.
As for the protocol, I could have sworn that users do not type protocol data
units directly, or at least that they haven't for roughly 25 years. (Another
jibe, citing the fact that utf-8 is, itself, a modification to "raw" unicode
is probably worth repeating, here.)
JCK> in the body of a message... where the only parts of that
JCK> sentence (appropriately translated) which are a ASCII characters
JCK> are the @-sign and _maybe_ the TLD (whether the TLD can be
JCK> non-ASCII is presumably an ICANN problem unless the user
JCK> interface does something akin to draft-klensin-idn-tld-01.txt).
Indeed, representation of non-ascii addressing information within a text
segment is an interesting problem. I'd guess it's identical to the business
card requirement.
And the current issue is no different than we have for IDN.
So perhaps the right thing to do is forget about IDN. Pretend it never
happen. Let's start all over.
Or, perhaps we could complete the design approach started by IDN, while
_separately_ pursuing the purist approach of end-to-end 8-bit.
JCK> So please don't prejudge the question of what happens to the
JCK> domain part (right hand side) of an email address in the
JCK> charter: this set of issues should at lease be considered very
JCK> carefully.
Indeed it should, including tidbits like adoption barriers, and the last
several years of IDN work.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>