Re: Normalisation and matching

At 09:11 03/08/11 +0000, Adam M. Costello wrote:

>Dan Oscarsson <[email protected]> wrote:

> > IMAA should define how non-ASCII e-mail addresses are used in
> > protocols, not how a user interface should handle them.
>
>Just the opposite.  Initially, non-ASCII mail addresses will not appear
>in protocols at all (only ASCII address will), but they will appear in
>user interfaces.  The primary issue that IMAA needs to address is how
>to bridge the gap between non-ASCII user interfaces and existing ASCII
>protocols.  Non-ASCII mail addresses won't appear in protocols until
>new protocols are defined, and each new protocol can then specify how
>non-ASCII mail addresses are to be represented in that protocol.  If
>normalized Unicode is the best way, then that's what they'll specify,
>but there's no need for us to prescribe that choice now.

I don't think I agree here. We want protocols to work together
easily. We want them to be able to just say 'use this'. We don't
expect them to rehash the discussions we have here. If they do,
they probably won't get the best result, because they don't have
the internationalization expertize that we have.
Also, we want new protocols to pick up on IMAAs. We should make
it easy for them to just point to a definition in our spec.


> > You do not want to spend resources on matching @ with "wide @".
>
>Obviously *you* don't.  When you define an IMA-aware protocol, you are
>welcome to restrict the syntax so that receivers don't need to bother
>checking for fullwidth @.
>
>But there may be some protocol designers who believe that it's important
>to preserve not only mixed case, but also other presentational
>details that would be destroyed by normalization (like a fullwidth
>@, or a superscript 2).  They might decide that it's better to
>transmit/display/store the mail address exactly as it was originally
>typed, and perform the normalization only momentarily for the purpose of
>matching it to the appropriate mailbox, and then discard the normalized
>form.
>
>There is no need for us to decide this question now for all future
>protocols.  As long as the equivalence relation is standard, each
>protocol can use whatever equivalent form it thinks is best.  Gateways
>between protocols will of course need to respect the requirements of
>each protocol, and perform any necessary translations, but that's the
>nature of a gateway.

Let's make sure gateways are as easy as possible, and don't have
to deal with issues that protocols maybe even forgot to specify.


Regards,    Martin.