----- Original Message ----- From: "Paul Hoffman / IMC" <[EMAIL PROTECTED]> > > > >"NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." > > Quite true. I think the following simpler statement is also true: > "UAX21_casefold(NFC(x))) == 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>. > > True, but irrelevant. Nameprep is called from IDNA. IDNA does not > say, and has never said, "you can do NFC before processing the name". > The fact that you might have done some processing on a name *before > you processed IDNA*, and that pre-processing may cause you some > surprises, is not an IDNA problem. <I dotabove>==<I><dotabove> : these two represent the same character. Likewise, <A acute>==<A><acute>: so do these two . But, for the latter case, stringprep treat them as equal ones,but for the former case, it doesn't. it is inconsistent, and moreover errornous,because LOWERCASE(<I><dotabove>) != <i><dotabove>.
IDNA inherits the error of UAX21. Therefore , this is IDNA problem, because IDNA adopted the problematic UAX21 without patches, even though IETF is not directly responsible for the specific error in UAX21.
