Re: Global and national e-mail address

Dan,

I don't think so, for at least three reasons, however 
unfortunate they may be...

(i) Absent tagging, we only get one shot at characters with the 
eighth bit set.  To say "ok, let's use 8859-1", is likely to 
turn out to be equivalent to "can't use UTF-8, or any other 
plausible Unicode encoding" in email, even within a country". 
That would be a very bad outcome, bad enough to encourage local, 
non-interoperable, conventions.

(ii) It is not even clear what characters are part of "the full 
Latin (sic) alphabet".  Note first that Latin itself uses a 
_subset_ of the characters that appear in ASCII.  Conversely, 
8859-1 contains most Western European "Latin" characters, but 
leaves out several that are needed to write Eastern European 
languages that use "Latin" scripts.  If you put all of those 
"Latin" characters together, there isn't room in a single 8-bit 
set, and then we start facing all of those "other" problems... 
might as well just give it up and use Unicode, rather than 
figuring out who picks what is, and is not, important enough.

(iii) "Latin", perhaps more than most other scripts (but that is 
getting past the limits of my knowledge; I hope Michael Everson 
will comment), has a long history of interesting and artistic 
fonts, some of them barely readable without contextual clues to 
those who use the underlying scripts every day.  As soon as one 
moves away from those basic 36 characters (or maybe a bit 
fewer), understanding whether adding sundry dots, hooks, bars, 
etc., in assorted orientations are font decorations or different 
characters actually requires a good deal of training and 
script-familiarity. To take an example from a different 
alphabetic script, many Thai characters, as conventionally 
written, contain small loops.  Can those loops be omitted 
without changing the character?  I don't know and presume you 
don't either.  I'm sure any Thai schoolchild does.  If you think 
there are firm rules that apply across scripts and make 
recognition reasonably easy for people who are not trained in, 
and regular users of, the script in question, please try 
explaining just how long the descender on a "j" must be 
--independent of font stylizations-- in order to turn it into an 
"i". And that example, of course, doesn't even require going 
beyond ASCII.  As I have noted many times before, our colleagues 
at ISO and ITU continue to select _extremely_ limited character 
sets when they want international interchange.   The reasons are 
no longer primarily a shortage of bits.

I continue to believe that, realistically, we are destined to a 
world of email address aliases if we want interoperability to be 
preserved.  For better or worse, we know how to do that and have 
been doing it for years -- as far as either 821 or 822 or their 
successors are concerned, "DAN" and "Dan" and "dan" in your 
address are aliases, not automagic case mappings... treating 
them as case mappings is merely an implementation decision.  In 
that context, I note that, if your system is case-sensitive for 
addresses (without aliases) and I assume otherwise and try to 
send mail to [email protected], the mail will 
bounce.  We have been living with this for many years; few 
people are surprised by it very often.

What does that mean in practice?  It means that my hypothetical 
friend Ug, who lives in Lower Slobbovia and wants to communicate 
with his Lower Slobbovian friends in their native script, is 
likely to want an email address in Lower Slobbovic.  I would 
hope that he would first hold a discussion with UTC and wait 
until the script appears in Unicode 4.99, but I'd predict, given 
a sense of urgency and/or being left out and the traditional 
behavior of Slobbovians toward standards, that they would use 
private-use Unicode space and adopt their own standards/model. 
If he wants to hear from you or me (or most of the rest of the 
world, including Upper Slobbovians, who have different case 
conventions at least), he is going to need an ASCII address 
(just as you need lower-case alias capability) -- the absolutely 
worst threat to interoperability involves our receiving a 
Unicode-based address that contains private-use characters (and, 
for a receiving Unicode 3.2 system, characters that are first 
defined in 4.0 may not be much better)... even cut and paste may 
not work, depending on the operating system environment.

As a final observation, please note that the "send UTF-8 (or 
something) in transport" and the "IMAA-like codings so transport 
doesn't need changes" differ only trivially under the scenario 
I've outlined above.  Under an idea set of conditions and 
assumptions (even though the ideal conditions are slightly 
different), things will work relatively smoothly with either. 
It is the edge cases that make the difference.  My Slobbovian 
examples are always about edge cases, but, even for the less 
extreme ones, the questions are about whether we can have 
localization where it is important _and_ global 
interoperability, or whether we need to start making "that 
script and the conventions of that language --and whether or not 
people can spell their names correctly-- are more important than 
that one" decisions.   I'm not prepared to either volunteer to 
be one of the human sacrifices the latter course is likely to 
require, or to volunteer anyone else.  My search for "do it 
right, even if it isn't quite as fast" solutions is based on the 
believe that we shouldn't sign IETF up for that role either.

     john


--On Monday, 08 December, 2003 13:27 +0100 Dan Oscarsson 
<[email protected]> wrote:

> This topic has been up before but as it may affect the
> proposals for handling alternative addresses, I think we could
> discuss it a little more.
>
> There have been some talk about having an address people can
> remember, speak over the phone, have on paper or business
> card. I think some of you see the old ASCII e-mail address is
> the suitable "global" address that everybody should have as a
> common address everybody can use. And some national version
> that only some will use.
>
> Unfortunately the 26 letters of ASCII are not sufficient to
> represent all names in the world in a good enough manner. Not
> all sounds can be represented well. But the easies thing for
> everybody to use, is an alphabet. So ideographic characters
> are out. Phonetic letters would work well for writing names,
> but are difficult for most people to use.
> Best choice I can see to use for "global" e-mail addresses is
> the Latin alphabet. Many today have a knowledge of how the
> glyphs look and can recognise them. Also many can type through
> the keyboard at least a subset of all letters.
> The Latin alphabet is not ASCII, the Latin letters include
> several letters more then the 26 in ASCII, for example, åäöæþ
> (for those who can see ISO 8859-1), as well as several accents
> that can be used together with the letters. Still the number
> of letters are not that many, and neither are the number of
> accents, so everybody should be able to learn to recognise and
> use them.
> Using the full latin alphabet instead of the ASCII subset, I
> think most (if not all) names can be written quite well.
> It is also good for everybody to get a little extended
> understanding of other cultures than their own.
>
> As people want to use a name written using national letters,
> they will need one or more national versions in addition to
> their global address.
>
> From the above, my choice for representing the Global e-mail
> address (the address everybody will be able to use) is to use
> the full Latin alphabet.
>
> This means that we should move the current infrastructure for
> e-mail so that everybody will, as a common subset, support all
> latin letters in email addresses. This subset can more easily
> be downgraded into ASCII to be used in legacy systems, that
> complete UCS, and can be made more easy to read in encoded
> form.
> At the same time it will allow most people to write their
> name/e-mail address in a way the closely represents their name
> as written using national characters.
>
> What do you think?
>
>    Dan
>
>