Re: Problems of Internationalized Mail Address eXtensions (IMAX)

>>Shouldn't Greeks and Japanese (as well as everyone else) have easy 
>>and equal access to those characters -- and to all others char sets 
>>in the Unicode database as well? Designing things on a language 
>>specific basis looks like a "no matter how many times you cut it, 
>>it's still too short" type of thing.
>
>Sorry for having created confusion by maybe stating my opinion in a
>somewhat simplified fashion. Of course, if we would go so far
>as to create different designs for Greek and Japanese, and so on,
>we would end up in deep chaos. The idea is just that the system
>is designed so that everybody can easily deal with the characters
>they mostly use. If somebody is familiar with math symbols and
>wants to use them for mail addresses (I personally doubt that
>there will be much such use, but that's not the issue), then
>they should be able to just use them, without having to go
>through an ACE.
>
>Regards,    Martin.


Martin:

I believe that the answer will come from commercial software 
designers and not from the creators of ACE (or whatever the end 
algorithm will be). I believe that whatever encoding is used (i.e., 
xx--whatever) to stand-in for a seven-bit to eight-bit conversion 
will be converted to/from the user via Internet end-user software. I 
don't think the end-user will ever have to see, or understand, what 
an ACE-like encoded string is.

Hardware and software developers clearly want a global market and 
adopting an Unicode-like database is one way, if not the only way, to 
accomplish that goal. Likewise, adopting an ACE-like algorithm for 
delivering an eight-bit message via a seven-bit medium has been the 
only way to fulfill that goal without trashing the net in the process.

The end result I envision, as do many, is a Chinese sitting before 
his keyboard using a Chinese char set to converse with his brethren 
with absolutely no regard for, nor reliance upon, English -- all 
AMC-like mechanics (i.e., the Latin alphanumerics) will be completely 
transparent to him. As a side note, his preference to his language 
char set will be as easy for him to set as it is for us to change 
from a Helvetica to a Times font. Please note that this is will done 
via end-user software and not through the efforts of this group or 
any group like it.

Eventually, I believe that the net will adopt an eight-bit format (or 
greater) and all this punycode and other such "make-fit" conversions 
will be nothing more than a uncomfortable growing-pains footnote in 
history. But until then, we will have to make due with what's 
available, and in doing so, provide opportunity for others to solve 
and meet end-user needs.

Now with that said, this list is a discussion as to what to do with 
the LHS of email addresses. I claim that keeping/treating both sides 
the same will simplify and speed the process for developers and will 
get this global opportunity to the end-user sooner. However, this 
will (and may unnecessarily) limit opportunities for the global end 
user. Keep in mind, that case considerations made by us (the English 
speaking people) does not have the same implications as it does for 
the rest of the world. In other words, we have made a distinction 
that UC/LC means something and have extended, or rather imposed, that 
limitation globally. So, the question to this list is -- should we 
continue to impose the same restraints on the LHS as we have for the 
RHS -- or should we consider that the LHS of the argument different 
and be treated with less restriction and thus more opportunity -- 
opportunity, I might add, which is not without problems in 
implementation.

tedd
-- 
http://sperling.com/