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

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "Paul Hoffman / IMC" <phoffman@imc.org>
 > >
> >"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.