Another round of IDNAv2, and thoughts on IDNA2008 goals

Paul Hoffman phoffman at
Wed Mar 4 20:20:12 CET 2009

Greetings again. I have just posted another version of my IDNAv2 proposal; <>. The main change in this version is to reverse my removal of the ZWJ and ZWNJ characters from the "mapped to nothing" list, thereby leaving IDNAv2 bits-on-the-wire compatible with IDNAv1.

This reversal comes from some very cogent points that John Klensin made to my last draft, and I think I see where the goals of IDNAv2 and IDNA2008 can be more easily differentiated. If the WG adds some mapping to IDNA2008 (which I think it needs to, particularly in light of draft-jet-idnabis-cjk-localmapping-00.txt), then we have brought the two proposals to some level of technical parity. That is, both proposals have lists of the allowed characters, and both have some mapping due to language and script expectations.

This leaves the primary difference between the two the major goal of IDNA2008: to create a framework that is independent of Unicode version, that is, that does not need to be changed in the future as the Unicode Consortium comes out with new versions of the Unicode Standard. IDNAv2 definitely doesn't try to achieve this goal, and I have added a few sentences about that in the introduction.

The WG then gets to consider the tradeoff: is the lack of compatibility from IDNA2003 to IDNA2008 worth the goal of no future updates to IDNA2008? Is that goal even achievable? I would have hoped so, but I am far from convinced that the Unicode Consortium could continue to add characters without us needing to change some of the rules in the IDNA2008 tables.

In preparing IDNAv2, I think that the amount of work that is needed might be much, much less than is still needed to carefully add appropriate mapping to IDNA2008. We keep hearing "we are almost done", and we keep finding language and scripts that need attention to deal with the changes in IDNA2008.

I do not pretend that IDNAv2 is wonderful. It has all of the cut corners and compromises that we made in IDNAv1. I would not be surprised if the WG decided that fixing those in IDNA2008 is the better way to go, even if it means introducing new problems, but I would also not be surprised if the WG said "let's just go with IDNAv2 now" and be willing to do IDNAv3 in a few years. If the WG goes with IDNAv2, I certainly don't think we should wait six years for IDNAv3; it should be much sooner than that.

More information about the Idna-update mailing list