Dave, (distro trimmed to IMAA and IETF lists; I hope we can soon get rid of the latter too). One large problem with the charter draft (I'm too tired to know if there are small ones)... If one is going to consider internationalization of email addresses in a way that permits them to move through the mail protocol in some traditional Unicode encoding (e.g., UTF-8), then I believe that we at least need to entertain the notion that what we are going after is "mailbox", rather than "local part". Yes, the hard work lies in the local part. But, to me, the goal is to have an I18N presentation form that is also carried over the protocol. That implies that one should be able to have local-part-i18n@FQDN-i18n (UTF-8 on both sides or, if you prefer, throughout the string (since the coding of "@" in UTF-8 is the same as it is in ASCII) rather than, e.g., local-part-i18n@FQDN-IDNA (UTF-8 on the LHS, but punycode for any domain labels that use non-ASCII). Again, the goal is that this should be natural for the user, using the user's script (or the script of the recipient), both in protocol transactions and in the case of "My email address is xx@yy." in the body of a message... where the only parts of that sentence (appropriately translated) which are a ASCII characters are the @-sign and _maybe_ the TLD (whether the TLD can be non-ASCII is presumably an ICANN problem unless the user interface does something akin to draft-klensin-idn-tld-01.txt). If the email address the user sees _looks_ like local script in the local part, but is forced into ASCII/punycode in the domain part, I think the users will assume that we have been smoking something. And, arguably, they will be right --punycode is a way of transporting internationalized data so it doesn't foul up other systems or cause DNS damage. But, from the user standpoint, however much users hate, e.g., a string representing a name transliterated into Roman characters, they will hate looking at punycode-- which has no mnemonic value at all for non-Roman scripts-- even more. So please don't prejudge the question of what happens to the domain part (right hand side) of an email address in the charter: this set of issues should at lease be considered very carefully. john --On Monday, October 27, 2003 16:19 -0800 Dave Crocker <dhc@xxxxxxxxxxxx> wrote: > Folks, > > On the theory that discussions go better when they have a > concrete deliverable, here is a proposed charter for a > proposed working group. > > The following started with Mark Crispin's text, although it > might not look it. Besides the usual goals for a charter, the > following text attempts to specify the problem domain in the > narrowest feasible form that is valid. If anyone thinks the > scope is too narrow, they need to explain why. > > > > DRAFT CHARTER > > Mail Internationalised Local-Part (MILP) > --------------------------------- > > The <local-part> portion of RFC2822 and <Local-part> portion > of RFC2821 mail addresses are restricted to a subset of ASCII. > This poses a fundamental barrier for users needing mail > addresses to be expressed in a richer set of characters, such > as Latin characters with diacriticals and the many Asian > characters. The goal of the current work is to add local-part > support for these additional characters, while preserving the > large, installed base of ASCII usage. > > The group will take: > > draft-hoffman-imaa-03.txt > draft-klensin-emailaddr-i18n-01.txt > draft-duerst-iri-04.txt > > as input to discussions. > > The group will pay particular attention to barriers to > adoption and utility, as well as any impact the new scheme > might have on the existing base of Internet mail usage. > > > Milestones > ---------- > > Nov, 03: BOF > > Dec, 03: WG chartered > > Feb, 03: Initial draft of working group specifications. > > Jun, 03: Specifications submitted for IETF approval > > > d/ > -- > Dave Crocker <dcrocker-at-brandenburg-dot-com> > Brandenburg InternetWorking <www.brandenburg.com> > Sunnyvale, CA USA <tel:+1.408.246.8253> > > >