Re: Normalisation and matching

Martin Duerst <[email protected]> wrote:

> > 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.
>
> We want protocols to work together easily.  We should make it easy for
> them to just point to a definition in our spec.

If we really want IMAA to make a recommendation about how IMAs are to
be represented in IMA-aware slots, then we'll need to agree on what
recommendation to make.

[What is the sound of a can of worms opening...]

Guess what recommendation I would argue for?  Minimal restrictions.  I
would recommend that IMA-aware protocols allow all valid IMAs (including
non-Nameprepped ones) in whatever charsets they want to support (and
they should at least support UTF-8, as recommended by BCP-whatever).
Applications should not apply Nameprep or NFC or anything before
putting the mail address into the slot; they should leave that to the
receiver to do if necessary.  (It will be necessary if receiver wants
to compare the address, or relay it into a IMA-unaware slot, but not if
the receiver merely wants to relay it into an IMA-aware slot, or display
it).

I see two advantages to this approach.  First, it allows presentational
details to be preserved (like fullwidth characters, superscript
characters, sharp-s, etc).

Second, it reduces superfluous computation at the sending end in
two cases.  Case 1:  If the receiver doesn't need the string to be
Nameprepped, then it would be a waste for the sender to apply Nameprep.

Case 2: If the receiver needs the string to be Nameprepped, then it
will probably apply Nameprep itself, even if the protocol says the
string should already be Nameprepped on arrival, in which case applying
Nameprep at the sending end is redundant.  Unlike IRIs, where the
receiver doesn't know whether it's safe to perform normalization (as
described in section 5.3 of the IRI draft), it is always safe to perform
Nameprep on local parts and domain labels (safe in the sense that the
result is guaranteed to refer to the same domain/mailbox).  Therefore,
just as web browsers try to interpret bad HTML rather than give up,
applications would in practice accept non-Nameprepped equivalent forms
even if the protocol said they were supposed to be already Nameprepped.
(And unlike the bad HTML case, there's not even any ambiguity; the
meaning is clearly defined by IMAA.)

So the approach I would recommend is to let applications take
responsibility for applying Nameprep when they themselves need it, don't
depend on other applications to pre-apply it for you, and don't bother
trying to pre-apply it for someone else.

This approach satisfies the properties you said you wanted:  (1) It
is easy for protocols to interoperate, they just need to obey the
requirements in IMAA, applying Nameprep whenever they are required to
(that is, when performing comparisons and when converting to ASCII
form) and at no other time.  (2) New protocols can simply point to a
definition in the IMAA spec, namely the definition of IMA.

So that's the recommendation I would prefer to make, and those are
my reasons.  I would very much prefer not to make the opposite
recommendation (that is, to recommend that senders pre-apply Nameprep).
I'm quite willing to compromise by making no recommendation at all,
leaving the decision in the hands of the IMA-aware protocol desigers,
but that's where we started...

AMC