Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> wrote:
IDN will soon be a practical reality, and non-ASCII characters in
e-mail addresses will probably soon be common also in the localpart of
the e-mail address.
IDNA has nothing to do with email address local parts, but perhaps you
are alluding to IMAA (http://www.imc.org/ietf-imaa/) which is a work in
progress and is similar to IDNA.
many people will have business cards with English information on one
side, and information in their own language on the other side. They
will then also have two e-mail addresses, since the ASCII version of
IDN should obviously be hidden from humans as much as possible.
The English side of the card could show either a separate "English"
email address, or it could show the ACE form of the same address that
appears on the non-English side of the card.
The advantage of creating a separate address is that it would be much
easier to remember and type, but there would also be advantages in using
the same address on both sides.
For example, suppose I have the cards of two people from Korea and I
send a single message to both of them. I cannot type Hangul characters,
so I use the ASCII addresses. If they are separately-created "English"
addresses, they might be intuitive to me, but they might be completely
non-intuitive to the recipients when they each look at the other address
in the To: field. On the other hand, if the ASCII addresses are the ACE
forms of the Korean addresses, they will be tricky for me to type in,
but will be displayed to the recipients using Hangul characters.
Also, if I put the ACE form in my address book along with the romanized
form of the person's full name, and later receive (directly or
indirectly) a message from that person in which the full name is Korean,
my mail program could recognize that the address matches an address book
entry and could show the romanized full name from the address book (in
addition to or instead of the Korean full name from the message header).
But the unwieldiness of the ACE form might trump all its advantages.
One of the areas where MIME still, ten years after its introduction,
often fails is when people copy e-mail messages into the bodies of new
e-mail addresses. Quite often, you see text encoded according to the
e-mail heading rules for non-ASCII characters in the bodies of such
messages.
It's not clear what is the "right" thing to do in this situation.
By the way, if messages were simply attached, instead of copied into
the body, then there would be no problem. The header would not be
transformed in any way until it was displayed by the final recipient.
But when headers are copied into message bodies, there are two
approaches. (1) You can do a simple copy of the ASCII header itself,
resulting in MIME-encoded and ACE strings that look like garbage. But
this results in a valid message header, and anyone (even someone using
a legacy mail program) can paste the fields back into the header of a
new message, where they will once again work properly. (2) You can copy
the non-ASCII text that would be displayed. The result looks nice, but
is not a valid message header, and pasting the fields back into the
header of a new message will not work on old mail programs (which don't
know how to re-encode the non-ASCII text), but might work on new mail
programs.
there will maybe be a need to extend the existing e-mail standards,
so that the e-mail address of especially From and Sender fields
can be specified in a dual format, with both the national and the
international (ASCII) name specified at the same time. Is this
something IETF should begin thinking about? Or is it something IETF
has already started thinking about?
IMAA will allow a single address to have both non-ASCII and ASCII forms,
but the ASCII form will look like garbage. IMAA restricts its attention
to individual addresses; it is not designed to express connections
between distinct addresses. For that I think you'd need something that
looks at larger pieces of message headers.
Bruce Lilly <blilly(_at_)verizon(_dot_)net> wrote:
I don't know of any provision for language tagging for IDN...[*]
* Unicode 3.something introduced a set of codes for language tagging,
but they do not use standard language tags (which are specified using
a subset of US-ASCII), they of course are not available in earlier
versions of Unicode implementations
And they are not allowed in IDNs anyway (Nameprep prohibits them).
It would be no good to have language tags be part of the identifier;
we wouldn't want the very same string of characters to refer to two
different mailboxes depending on whether it was tagged as Chinese or
Japanese. Language tags would have to be markup around the identifier,
which would have to be done at a higher layer than IDNA (for example, by
extending the message header syntax).
Claus Färber <list-ietf-rfc822(_at_)faerber(_dot_)muc(_dot_)de> wrote:
From: Claus Faerber <claus(_at_)faerber(_dot_)muc(_dot_)de>
(INT: Claus =?ISO-8859-1?Q?F=E4rber?=
<claus(_at_)xn--frber-gra(_dot_)muc(_dot_)de>)
A MIME-aware IDN-aware user agent would decode the alternate
display-name, but not the alternate addr-spec. Therefore it might be
better to put the ASCII form in the comment:
From: Claus =?ISO-8859-1?Q?F=E4rber?=
<claus(_at_)xn--frber-gra(_dot_)muc(_dot_)de>
(ASCII: Claus Faerber <claus(_at_)faerber(_dot_)muc(_dot_)de>)
This way everything would be decoded and displayed nicely by a
MIME-aware IDN-aware user agent.
Or not... I just tried this with mutt and discovered that it refuses to
show address fields as-is, even when I explicitly ask to see the whole
header. If a mailbox has a display-name, then its comments are not
shown; if it has no display-name, then all its comments are concatenated
and converted to a display-name (quoted if necessary).
I don't know if other mail programs would be quite so heavy-handed
as this, but I wouldn't be surprised if they failed to preserve
address-field comments in replies.
AMC