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

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

Is the following issue    addressed or mentioned in new stringprep/nameprep draft?

<I dot above> and <I><dot above>  represent the same character. that is, they are NFC-equivalent.
But, UAX21 (casefolding in stringprep) maps the latter one errornously into <i><dot above> 
(very different than the correct one <i>). 
In lowercaseing, <I><dot above> should be converted as a whole, instead of by char-by-char basis.
 
Stringprep should have contained warnings about this or included new revised casefolding operatins/tables,
but it didn't . the authors and co-chairs have ignored this repeated warnings 
without any responses in this list. This is not a theoretical issue, 
but a practical issue because the sequences are used by modern east-europeans.

Therefore,stringprep(NFC(x)) == stringprep(x)  is not guaranteed. This will cause unnoticeable failures.

It's ridiculous that repeated warnings are ignored/unanswered and the drafts went to IESG.
This will result in downplay on overall IETF processes and its reputations.

Soobok Lee


----- Original Message ----- 
From: "Soobok Lee" <lsb@postel.co.kr>
To: <idn@ops.ietf.org>
Sent: Tuesday, February 12, 2002 1:39 AM
Subject: [idn] IDNA comment 1 : applications' own normalization vs stringprep


> 
> In the IDNA draft version6,  section 6.1, paragraph 4 and 5,
> 
> "In protocols and document formats that define how to handle
> specification or negotiation of charsets, labels can be encoded in any
> charset allowed by the protocol or document format. If a protocol or
> document format only allows one charset, the labels MUST be given in
> that charset."
> 
> "In any place where a protocol or document format allows transmission of
> the characters in internationalized labels, internationalized labels
> SHOULD be transmitted using whatever character encoding and escape
> mechanism that the protocol or document format uses at that place."
> 
> Here,we need more security warnings in this section regarding to applications'
> own normalizations that may collided with STRINGPREP's NFC/NFKC.
>  
> Like some XML and HTML  standards, there may be applications that performs
> NFC,NFKC or other normalizations on their data/text contents that 
> may contain IDN labels that will be stringprepped and the ACEed later time.
> 
> But, even in the case NFC, stringprep(NFC(x)) == stringprep(x) is not always 
> guaranteed, especially in the case of <I dot above> and <I><dot above> ( + <acute>).
> That will cause silent failures in applications.
> 
> Current premature UAX15 used in stringprep and other compensating or superior normalizations that may
> be from the same UTC or other organizations  may collide to each other in
> a sequence of normalizatiom processes eventually ending in stringprep  
> in many mission critical applications.
> 
> We need more researches and inspections for the possiblities of normalization vs normalization
> conflicts and include the warning or recommendations in the IDNA specficiations.
> 
> Soobok Lee
> 
> 
> 
> 
>