Re: Standard mail address

Adam M. Costello wrote:

>Mail addresses are both protocol elements and text strings.  When
>they're on the wire, they're primarily protocol elements, and the
>software looking at them doesn't care whether they're pretty or ugly.
>When they're being displayed to users, they're playing the role of text
>strings, and then it matters whether they're pretty or ugly.

Software cares a lot if they can be handle easy. And it is us humans that
create the software. Internationalisation is very important for
software, not just humans.

>
>The very first places that IDNs will appear is in user interfaces. 
What is an IDN? A ACE version of a domain name?
A domain name does not need to be internationalised as it is just a
sequence of characters (any character), but software need to be
internationalised if it cannot handle non-ASCII.

> It
>may be a while before non-ASCII IDNs appear in any protocols, because no
>existing protocols understand non-ASCII IDNs, and there's no pressing
>need to create new protocols that do understand them. IDNA didn't spend
>any effort defining how to use non-ASCII IDNs in protocols because
>there's no pressing need for that.

There is a lot of pressing need of being able to handle normal domain
names (and URLS, and e-mail addresses) directely in protocols and
software. Encoding them into ASCII and sending them over legacy
protocol contexts is NOT acceptible. Only as a transition mechanism.



>
>> The above do not mean NFKC.  It more means NFC with all characters
>> having multiple code points in UCS replaced by one (or alternatie
>> forms forbidden).
>
>But that's what NFKC is for.  It's like NFC, except that characters
>having multiple code points (like A and fullwidth A) get replaced by
>one.

Not at all NFKC does change many code points, which are not representing
the same character, into one. Only code points that represent the
same character, must be replace by one code point.

>
>> It also means that case-insensitively is done by simple one-to-one
>> character case-insensitively,
>
>The Unicode Consortium has a standard for doing case-insensitive
>comparisons.  Who are we to "fix" it?  The decision was made for IDNA,
>and I don't see why we should do it differently for IMAA.

No need to fix it. The Unicode include in the standard character database
all upper/lower case matchings. That is the one you should use.
You should not use the additional special mappings that includes
one to many character mappings. That is defined by Unicode in a seperate file
that can be used in addition to basic character database.

>
>> probably including the SC/TC matching.
>
>IDNA has no provisions for SC/TC matching in the domain part, so there's
>no point in IMAA providing for SC/TC matching in the local part.  People
>are working on server-side solutions for domain names (using aliases,
>for example), and the same people can work on server-side solutions for
>the local part (again, using aliases, for example).

Just because IDNA ignored this does not mean that it should not be here.
matching of domain names should include SC/TC also.
IDNA does only define a way to encode some of all domain names into ASCII.

>> During encoding into ASCII a Standard mail address may not be changed,
>> not lower cased or in some other way, so all sematics is preserved.
>>
>> Using the above form there are no problems in having both
>> case-sensitive and case-insensitive mail addresses.
>
>Yes there is.  Consider the local parts josé and JOSÉ.  You say they
>are not case-folded before being converted to ASCII.  That means
>they map to two distinct ACEs, like iesg--jos-dma and iesg--JOS-pia.
>Any mail server that now exists will treat those as unrelated local
>parts belonging to two distinct mailboxes.  For example, one person
>might create [email protected], and another person might create
>[email protected].  Now josé@yahoo.com and JOSÉ@YAHOO.COM are two
>different people.  Who wants that?

If you want to use non-ASCII mailboxes you should fix your software to
handle non-ASCII. Only the server having the mailboxes need to be fixed.
We should not create limits because somebody does not want to fix their
software. It is not needed in the mail area. If you want to support
mailboxes with non-ASCII on your server - fix your software first.

Any comparing of equality of e-mail addresses must be done using
Standard mail address form. This removes all difficulties of
case differences or encoded forms.

We cannot make a lot of (for people) stupid restrictions on
mail addresses just because of legacy software. The needs of the
international community must come first.

   Dan