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(_at_)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(_at_)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(_at_)yy(_dot_)" 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(_at_)dcrocker(_dot_)net> 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>