Re: Normalisation and matching

Dan Oscarsson <[email protected]> wrote:

> But domain names converted to lower case is not as important as names.

The local part is no more a name than the domain part.  Both
are identifiers designed to be memorable in association
with a person/organization, not equal to the name of that
person/organization.  No one expects to exchange email with
<John Q. Public at Yahoo! Inc.>, they are accustomed to
exchanging email with "John Q. Public" <[email protected]>.

> Still it is bad that IMAA (and IDNA) gives a lot of impact on the
> international form that would not exist if you started from the
> international perspective.

Yes, but we don't get to choose our starting point.  Our starting point
is the ASCII status quo.

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

...and details that would be destroyed by case-folding, like sharp-s. :)

> > That makes it very clear that SS and sharp-s are supposed to match.
> > They both get folded to ss.
>
> I could accept that for matching, even though it is not correct in
> many cases.  But not when doing a lower case conversion.

Exactly.  Unicode specifies that ToLower(Laße) = laße, not lasse.  But
IDNA & IMAA don't do lower case conversion; they have no use for it.
What they need is case folding, because caseless matching is defined
in terms of case folding.  Unicode specifies that Fold(Laße) = lasse,
because Laße needs to match LASSE, and Fold(LASSE) = lasse.

> There are...code points that should never have existed, making
> everything unnecessary complex (like having to have NFKC because the
> same character exists more than once for some characters).

Some of those redundant code points (including fullwidth @) are there
for a good reason: to enable lossless round-trips from a national
standard character set to Unicode and back again.

AMC