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@yy." 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>