Re: Standard mail address

Dan Oscarsson <[email protected]> wrote:

> Reading through the IMAA draft I get the same mess of protocol and UI
> that I got in IDNA.

Not surprising, since IMAA is strongly patterned after IDNA.

> Also the focus is very much on legacy handling.

Yes, same as in IDNA, the goal is to allow non-ASCII mail addresses
to be used in end-user applications without needing to upgrade any
infrastructure.

> I can see three basic areas:
>    - legacy protocol context (current ASCII context)
>    - international protocol context
>    - user interface
> 
> I will not say anything more about user interface.  The importat area
> to start is with the international context.  And protocol level.

Internationalization (support for non-ASCII characters) is for the
benefit of humans.  Humans benefit from it when they can see the
non-ASCII characters in the user interfaces, regardless of what's on the
wire or what's being passed through library interfaces.

BCP-18 says:

    Internationalization is for humans.  This means that protocols
    are not subject to internationalization; text strings are.  Where
    protocol elements look like text tokens, such as in many IETF
    application layer protocols, protocols MUST specify which parts are
    protocol and which are text.

    Names are a problem, because people feel strongly about them, many
    of them are mostly for local usage, and all of them tend to leak
    out of the local context at times.  RFC 1958 [RFC 1958] recommends
    US-ASCII for all globally visible names.

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.

The very first places that IDNs will appear is in user interfaces.  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.

The situation will be the same for IMAs.

People who want to design new protocols that use non-ASCII mail
addresses can do that, but there's no need to delay IMAA while waiting
for that, just as there was no need to delay IDNA.

> 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.

> 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.

> 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).

> An ACE need to be used.  It need not be Punycode with is complex.  It
> could be SCSU with hex encoding which also give a fairely compact
> encoding.

Since every mail address includes a domain name, and the domain name
will already be using Punycode, the simplest way to encode the local
part is to reuse Punycode.  Adding a second encoding, even hex, would be
more complex, not less.

> 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?

AMC