----- Original Message ----- From: "Paul Hoffman / IMC" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, May 05, 2002 1:03 AM Subject: Re: [idn] 1st stringprep issue: not answered and ignored
> At 12:59 PM +0900 5/4/02, Soobok Lee wrote: > >Stringprep should have contained warnings about this or included new > >revised casefolding operatins/tables, > >but it didn't . > > Correct. This has been covered many times on the mailing list. You > want stringprep to change the tables issued by the Unicode Consortium > so that stringprep does not do NFKC the same way all other software > that does NFKC does. There is little support for that proposition in > the WG. I am not against NFKC. I am not proposing for modification to NFKC, but to UAX21 casefoldings. I just pointed our that The UAX21 casefolding is wrong at the example. Who had answered at my questions before your this article? How to measure the consensus? I have never seen this WG had discussed this issue in depth. > > > the authors and co-chairs have ignored this repeated warnings > >without any responses in this list. > > There is a big difference between "ignoring" and "disagreeing with". > We hear you asking over and over for something for which there is > little support. Are you saying that we should include the concerns of > every single person, even if the rest of the group disagrees with > them? > > >Therefore,stringprep(NFC(x)) == stringprep(x) is not guaranteed. > >This will cause unnoticeable failures. > > Your equation is completely wrong. NFKC is part of stringprep. Alas. You still don't get my point. The NFC(x) above is , for example, from IRI preprocessing or HTML authoring, which often require NFC normalization on their inputs. To rephrase the above equation, "NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." If you preprocess IDN with NFC, you will get different namepreped ACE labels than before in the IDN samples including <I><dot-above>. Soobok Lee > > --Paul Hoffman, Director > --Internet Mail Consortium
