In general, I think some of the specific recommendations in section 4
are poorly researched. I think it is bad advice to even suggest
people to look into the solution outlined in section 4.3. It seems to
me that adopting the approach would break backwards compatibility in
Unicode for most European languages, which would be a serious problem.
2.2.8. Versions of Unicode
...
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:
PR29], which was discovered after Unicode 3.2 was published.
Further:
There was community input that the change would cause problems for
Stringprep, but UTC decided, on balance, that the change was
worthwhile. Because of difficulties with consistency, some
deployed implementations have decided to adopt the change and
others have not, leading to subtle incompatibilities.
Similarly, here it would be useful that some IDNA implementers have
adopted the fix despite that it doesn't apply to Unicode 3.2, and that
IDNA reference Unicode 3.2 explicitly. The subtle incompatibilities
are not the direct result of Unicode Consortium's actions, but the
choice made by some implementers.
For the record, my implementation, Libidn, implement the original
Unicode 3.2 semantics.
I suggest replacing 'incompatibilities.' with:
incompatibilities, despite that the change does not apply to the
version of Unicode that IDNA uses.
Thanks.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf