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