On Thursday, April 20, 2006 03:05:43 PM +0200 Simon Josefsson
<jas(_at_)extundo(_dot_)com> 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+(_at_)cmu(_dot_)edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf