Re: [idn] 1st stringprep issue: not answered and ignored

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

The point that Soobok Lee shows is a very serious matter.
The requirement on the ACE form of IDNA is that the same
name must always result in the same ACE!!!!

If doing casefolding/mapping followed by NFKC results in a
different code point sequence than doing NFC, casefolding/mapping and
NFKC again, we will get DNS lookup failures due to names do not
match. While hopefully most data entered into stringprep will
be NFC, some will not.

If the above is true, stringprep/nameprep must be changed so that
the preparation steps for strings are:

1) See to that input strings is NFC.

2) all the steps in stringprep.


    Dan

--
Below i Soobok Lee's text:
>UTC casefolding (UAX21) is made for char-by-char casefolding,  not for
>combining sequences, but stringprep blindly applies UAX21 into them.
>That is not the problem of UAX21, rather  of the stringprep.
>
>NFCing before casefolding solves this problem, but this suggestion
>was also ignored or not discussed in depth.
>
>Without any modificationa to UAX21 and NFKC and NFC, we could cure
>this <I><dot above> stringprep errors, simply by adding NFC in
>step zero in stringprep.