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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf