Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes (Thu, 29 Apr 1993
22:22:47 -0400):
On my business card my email address would be given in two
forms, one containing non-ASCII characters, the other being the
real sequence of ASCII characters that form the RFC 822 address.
This isn't different from other possible solutions of the
"non-ASCII characters in addresses" problem I think.
I have a *very* strong bias against having multiple ways to spell
an email address.
Yes, in an ideal world where mail protocol designers got it
right the first time or no backward compatibility with older
protocols were needed ...
In general there is a tendency for each user to assume that his view of the
world is the same one that everyone else sees. As the local postmaster, I am
frequently asked to translate an address from one form into something that
will work with "our" mail system -- and before I can give an answer, I must
know whether the user uses UNIX, VMS, VM/CMS and PROFS, or a PC of some
kind...the instructions are different in each case.
One possible way out of this mess is a gradual transition to one
or two "universal" mail address formats that all other kinds of
addresses can be mechanically translated to or, even better,
replaced by. I guess that it's unavoidable that one of the
"universal" address formats will be X.400 addresses. The other
should in my opinion be Internet addresses "extended" to be able
to carry all text characters used in other formats or likely to
be demanded by future email users. This "extension" doesn't
have to include an extension of the range of octets allowed in
Internet addresses but only reinterpretation of a class of ASCII
character sequences that in any case are rarely used, as I have
tried to show in some detail.
Of course you are knowledgable enough to put both addresses on your business
card, but for your scheme to be successful, you must educate every email user
on the Internet about the (very subtle) difference in the two schemes.
This is a problem when communicating electronic mail addresses
on paper, not when the address is transferred electronically.
It's _not_ necessary to educate every user about the subtle
differences, everything a user engaged in international email
needs to know is that there are two forms of his address, the
usual national form and a more cryptic, international form.
That shouldn't be more difficult to grasp than the two forms of
one's telephone number
Nat 08-790 71 26
Int +46 8 790 71 26
(which also should be on the business card). In the near future
electronic mail will spread rapidly and be used by many more
people than now, just like telefax has. Most of them will use
it only for communication within their own country. These less
sophisticated users will not have to know anything at all about
the ugly international form of their email address.
... It's far easier to just hand
users an opaque string and be done with it
I don't think users of new mail software (implementing my
proposal for "enhanced address rendering") will have to take
notice of their primitive ASCII addresses much or at all. But
especially if they speak a language based on another script than
the Latin script, they will all, because of this enhancement,
experience some good properties of Internet addresses (that
American and English users always have taken for granted), for
example that email addresses are easier to learn and remember
than arbitrary character sequences like telephone numbers.
....we need to minimize the number
of different address syntaxes, not add more confusion.
My proposal doesn't introduce a new address syntax, it just
extends the range of visible characters that can be used. The
intention is not to increase confusion but to increase the
functional value of Internet addresses for users that don't have
English as their native language.
The real solution to this problem is not to make 8-bit user names work with
email, but to build a reasonable directory that can translate "real" names to
email addresses.
Directory systems like X.500 could be used to solve also this
problem of course, but solutions like my proposals are
orders of magnitude easier to implement and has therefore is our
only hope to get a working solution widely deployed on the
Internet in the near future.
... As user communities grow larger, addresses become less
meaningful anyway...there are too many name collisions for everyone to have
his name as his email address.
There shouldn't need to be many name collisions in the local-part of
email addresses with a wise use of sub-domains.
Any scheme to "translate" 8-bit names into ASCII is going to introduce some
instability and cause some pain as users adapt. If we have the directory do
the translation ... we gain additional functionality and we only have to go
through one transition.
I don't expect the sudden rise of a universal, all-embracing,
well-functioning, reliable, up-to-date directory service,
especially not as regards the use of extended character sets and
schemes for transliteration or transcription between different
languages and scripts.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>