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