(Forwarded from another list) > Patrik, the consortium does take seriously the relationship with the IETF. > Were it not for that, there probably would not have been a letter ballot in > the first place -- it would have simply been dealt with in the last meeting. > > As the discussion on this list and on > http://www.imc.org/idn/mail-archive/threads.html attest, this is not a > simple decision; there are good arguments on both sides. > > I myself favor option B -- I think it will cause the least disruption > overall, especially since those 5 characters are rare, and the mapping > tables from CNS 11643 to those characters are not widely deployed (and one > already has to handle cases of variant mapping tables: the JIS characters > that vary in mappings between different operating systems are a heck of a > lot more common!) > > On the other hand, should the UTC decide to go with option A, the > NormalizationCorrections.txt file does allow IDN to migrate to future > versions of Unicode while being strictly backwards compatible. And because > the mappings are one-way, to characters that themselves do not differ have > canonical/compatibility mappings in either case, an implementation can > *still* make use of a stock version of NFKC or NFC to do mappings. The > implementation just needs to have an additional preprocessing step, mapping > those 5 characters according to NormalizationCorrections.txt before applying > normalization. (We should make this point clear somewhere in the > documentation of that file.) > > So having NormalizationCorrections.txt does ameliorate the problem. I agree > with you and others that it does not *eliminate* the problem (that's why I > personally believe that B is the better course), but in practice either A or > B are tenable solutions. > > Mark
