Re: First strawman for UTF-8 headers proposal

On Sunday, November 30, 2003, at 09:56  PM, Simon Josefsson wrote:

> Keith Moore <[email protected]> writes:
>
>> Again, I really don't think having UTF-8 headers puts us much closer
>> to a solution to the problem at hand - which is to allow multiple
>> representations of addresses in different languages and scripts.  (to
>> which I might add -- without significant disruption of the mail
>> system).   At best, providing unencoded UTF-8 headers would be
>> orthogonal to a solution to the problem - actually I suspect it would
>> impede adoption of a solution.
>
> Could you define the problem you are thinking of here, more closely?

I did so a couple of weeks ago in a thread called "what is the real 
problem?"

> Being able to send UTF-8 in headers, after "fixing" SMTP, POP3 etc,
> between aware applications, would appear to give me non-ASCII e-mail
> addresses (and also get rid of RFC 2047, which is a nice side effect).

Non-ASCII email addresses are worse than useless if you can't 
transcribe them - which means at a minimum being able to display them, 
read them, write them down, and type them back in.  So either you have 
to use different addresses depending on whom you're corresponding with 
(and you need a way to keep track of who can use which address), or you 
need a means for mapping between different addresses for the same 
mailbox.  Without a means for mapping between equivalent addresses, 
non-ASCII addresses would essentially be used only by people who can be 
confident that ALL of their correspondents can display, read, write, 
and type those addresses.  This could exclude, for instance, your kids 
who happen to be studying in another country whose computers use 
different keyboards.  It certainly makes them impractical for use in 
most international businesses.

The problem of providing multiple forms of an address is the same 
regardless of whether you encode the addresses in UTF-8 or in some 
other (say ASCII-compatible) encoding.  In other words, encoding 
addresses in raw UTF-8 doesn't help you solve this problem at all.  All 
it does is impose additional barriers to adoption and cause additional 
failures.

(and no, it doesn't even get rid of RFC 2047, however nice that might 
be, because it will still be necessary to read old messages long after 
all MUAs support the new format)

And even if you argue that the address mapping isn't needed, addresses 
encoded in ASCII are still more universally transcribable than 
addresses encoded in raw UTF-8.  I suspect that such addresses are too 
ugly to use and that we'll want a mapping service that will translate 
between UTF-8 and "less ugly" ASCII equivalents.  But either way this 
is a lot simpler than upgrading  or replacing every single part of the 
email system, which is what going to raw UTF-8 implies.

You might say that MUAs can display an ASCII-encoded version of the 
UTF-8 address if the recipient doesn't understand that language.  But 
then you would be proposing to upgrade every mail handling program in 
the Internet just to get a functionality that could be had much more 
easily and quickly, and with far less expense and disruption, simply by 
encoding the addresses in the message header.

> You say you want multiple representations of addresses in different
> languages and scripts.  Is the "multiple" a goal in itself, that must
> be present at the protocol level?

The goal is to allow every recipient of the message to see each address 
in the message header in a form that he/she can remember and/or 
transcribe.  This won't happen, of course, unless there is such a form 
of the address for each recipient, and unless there is some way of 
providing a suitable form to each recipient.

> Why do you want to support multiple scripts?

Because some languages use more than one script, and I'm assuming that 
it might be useful to map between different addresses in the same 
language but are written in different scripts.  Saying "languages and 
scripts" is more general than just saying "languages".  As I see it, if 
you can supply alternates in different languages, you can supply 
alternates in different scripts for the same language just as easily.

>   What is missing from Unicode, that warrant the added
> complexities of character set tagging of data?  Applications on
> non-Unicode platforms can convert to and from their native encoding.

I didn't say anything about character set tagging, I've been assuming 
the Unicode repertoire is sufficient (maybe it is, maybe not, but I'm 
assuming it is for now).  You do need language tags because the 
decision of which address to present to a recipient should probably be 
based on language, and you can't always infer language from looking at 
the sequence of Unicode characters.