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

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

NB.
 UAX21 authors could argue that: UAX21 should be applied to strings which
is already  NFC-normalized. UAX21 is used improperly in stringprep.

 If we accept this excuse, stringprep should have applied NFC before casefolding
and then NFKC. This may introduce another inefficiency but it make stringprep
correct.

Soobok Lee

----- Original Message ----- 
From: "Soobok Lee" <lsb@postel.co.kr>
To: <idn@ops.ietf.org>; "Paul Hoffman / IMC" <phoffman@imc.org>
Sent: Sunday, May 05, 2002 4:30 AM
Subject: Re: [idn] 1st stringprep issue: not answered and ignored


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