Re: [idn] IDN rechartering rev 3, and nameprep

["James Seng/Personal" <jseng@pobox.org.sg>]

> This could be fixed by using the "simple" versions of case foldings
for
> characters that include ypogegrammeni or prosgegrammeni, and removing
> the folding for U+0345. (It isn't actually important to consider
> ypogegrammeni to be equivalent to iota, but uniform treatment of
> canonically equivalent strings is definitely important.)

Nameprep dont "fixed" NFKC. That is not the intention.
Nameprep reference NFKC and use it as-is.

If there is a problem with NFKC, then we have to fix it at UTC, not
here.

> Other issues relating to normalisation are:
>  - whether to use NFKC or NFC
>  - what set of characters to disallow (the current spec arguably
>    allows too much)
>  - treatment of Hangul compatibility Jamo
>  - the point raised by Kent Karlsson about Jamo clusters
>  - the definition of "stored" and "request" strings in stringprep

Most of the these issues have been addressed in the report by Nameprep
team in San Diego. Those that we didnt (such as Jamo), see the above.

> I frankly don't see how normalisation can be finalised without knowing
> which protocol proposal will be used, or why it's necessary to
finalise
> it before then.

Actually they are independent. Whether the solution is IDNA or not,
UTF-8 or ACE, we always need a normalization process. While we always
related Nameprep to IDNA or ACE, there is nothing in Nameprep which
enforces ACE or IDNA.

-James Seng