On Thursday, April 20, 2006 03:05:43 PM +0200 Simon Josefsson <jas@xxxxxxxxxxx> wrote:
An example of the type of change that appears to be just a small correction from one perspective but may be problematic from another was the correction to the normalization definition in 2004 [Unicode- PR29]. I believe it should be noted here that this was discovered after Unicode 3.2 was published, and consequently doesn't apply to the original Unicode 3.2. I.e., change 'PR29].' into:
Corrigendum #5, which fixes the inconsistency causing the problem described in PR29, _does_ apply to versions of Unicode from 3.0.0 through 4.0.1, including 3.2.
It is also worth noting that even for implementations which were based on the (normative but incorrect) text of the original 3.2 spec rather than the (non-normative but correct) sample code, changing to the corrected model will not "break backwards compatibility in Unicode for most European languages", because those combining sequences which trigger the inconsistency "do not constitute well-formed text in any known language" (Unicode corrigendum #5).
On the other hand, potential security issues caused by instability in the original (erroneous) definition are at least as serious as the potential incompatibilities caused by the change.
I suggest that folks who are interested in this issue read PR29 for themselves, rather than relying on Simon or myself for information.
I suggest replacing 'incompatibilities.' with: incompatibilities, despite that the change does not apply to the version of Unicode that IDNA uses.
This statement would be incorrect. The statement _does_ apply to the version of Unicode that IDNA uses.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf