Re: 1st stringprep issue: not answered and ignored

To discuss this problem, we have to know how the 
tables in stringprep is organized.  I wander if stringprep authors 
may have some thoughts. 

Liana Ye

On Sat, 4 May 2002 12:59:27 +0900 "Soobok Lee" <[email protected]> writes:
> 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" <[email protected]>
> To: <[email protected]>
> 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
> > 
> > 
> > 
> > 
> > 
> 
> 
> 


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.