ietf-822
[Top] [All Lists]

Re: Dual names, IDN and ASCII, in e-mail addresses?

2003-09-25 13:33:13

Jacob,

Your concerns are timely and reasonable.  However I believe they are misguided.

Here is why:


JP> This means that lots of people are going to have e-mail
JP> addresses like Göran(_at_)Müller(_dot_)de(_dot_) And one of the main

In order to see such addresses in their "native" form, when they are encoded
using IDN, people will need email (or other) software that understands IDN.
Hence, they will be using software that is "internationalized" in the
necessary manner.

Others will see the ASCII version of the IDN string. Although these will be
ugly, they are completely compatible with existing email software. They can be
typed, and copied, etc., with no change to that software.


JP> problems with such names is that people in other countries
JP> will have difficulty typing them. My guess is that many
JP> Americans will have problem typing Göran(_at_)Müller(_dot_)de, and
JP> typing names in totally different alphabets like Greek,
JP> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
JP> more difficult.

People are already faced with this problem. It is not new to email. In fact,
it has almost nothing at all to do with email or IDN.

It has to do with user interface support for multiple character sets. I find
typing Spanish, in my US version of Windows to be onerous. And that only
involves a few accent marks.

But this has nothing to do with email. It has to do with software support for
typing more characters than are supported on my keyboard.


JP> Because of this, many people will have business cards with
JP> English information on one side, and information in their
JP> own language on the other side. They will then also have
JP> two e-mail addresses, since the ASCII version of IDN should
JP> obviously be hidden from humans as much as possible.

This is no different from the challenges that people have long been facing,
concerning postal addresses and even telephone numbers.


JP> They might then use their national e-mail address for
JP> national mail, and their international e-mail address for
JP> international mail. And certainly mail intended for one
JP> region may get into another region, so that e-mail with
JP> national names in some heading field will often get resent
JP> internatinally.

JP> One of the areas where MIME still, ten years after its
JP> introduction, often fails is when people copy e-mail
JP> messages into the bodies of new e-mail addresses. Quite
JP> often, you see text encoded according to the e-mail heading
JP> rules for non-ASCII characters in the bodies of such
JP> messages.

This is not a failing with MIME.  MIME actually appears to have the right set
of labeling mechanisms.

The problems are with the software that uses MIME. Often, the user's system
does not properly mark the local "language" or "character set". Hence, the
MIME software does not label the content that is produced. They package the
content as MIME default, when it is not. (This is a good reason for having
global standards never have labeling defaults.)

So, when the sender's default actually is Kanji and the receiver's default is
really Spanish, they have a problem. The problem is not with MIME but with the
senders _use_ of MIME. This difference is fundamental.


JP> The conclusion of what I have written above is that there
JP> will maybe be a need to extend the existing e-mail
JP> standards, so that the e-mail address of especially From
JP> and Sender fields can be specified in a dual format, with
JP> both the national and the international (ASCII) name
JP> specified at the same time. Is this something IETF should
JP> begin thinking about? Or is it something IETF has already
JP> started thinking about?

There might be an interesting task, here, but not for the reasons you have
described.

What you are really describing is a desire to have multiple email addresses
identified as belonging to the same entity (person, or whatever). I think of
of this as being the same as having multiple A records for an entry in the
DNS.

The IDN-vs-ASCII motivation for having multiple addresses is just one example.

Interestingly, this capability was originally specified in RFC 733:

     address     =  host-phrase / quoted-string
                 / (*phrase "<" #address ">" )
                 / (*phrase ":" #address ";" )
                 / (":" ("Include" / "Postal" / atom) ":" address)

Note that the value inside angle brackets may be a list.

Although I thought it was reasonable and clever to permit this, no one ever
used it, so it was deprecated for RFC822.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>


<Prev in Thread] Current Thread [Next in Thread>