Re: 1st stringprep issue: not answered and ignored

The Unicode Consortium recommends that the tables in StringPrep be
updated to encompass Unicode 3.2, which was released in March.

As a part of this release, there was one change (in addition to new
characters) in case folding. The situation regarding the
dotted/dotless I in the case foldings has been cleaned up by providing
several options, one of which (full case folding without option T)
preserves canonical equivalence (although not normalization forms --
text still needs to be normalized after case folding).

http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt

Mark
__________

http://www.macchiato.com

"Eppur si muove"

----- Original Message -----
From: "Dan Oscarsson" <[email protected]>
To: <[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Monday, May 06, 2002 01:57
Subject: Re: [idn] 1st stringprep issue: not answered and ignored


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