Mapping tables (was Re: IDNA online tool)

John C Klensin klensin at
Sun Apr 12 09:54:18 CEST 2009


An observation on part of one of your recent notes...

--On Friday, April 10, 2009 10:01 -0700 Mark Davis
<mark at> wrote:

> Those
> of us who have worked in operating systems are also painfully
> aware of this kind of problem.

Indeed.  And those of us who have worked in both operating
systems and programming languages are perhaps even more aware of
it.  In the latter case, users discover compiler bugs, devise
workarounds, and embed them into code.  They, or even worse,
their successors are often furious when the bugs are fixed
because the workarounds stop working and no one knows (or
remembers) how and where to take them out.

But one must strike a balance between the needs of prior usage
(which suggest bug-compatibility between versions) and those of
present and future ones who may have a reasonable expectation of
not needing to rediscover those old bugs and devise new

> So even though Unicode could be improved in many ways with
> incompatible changes, we have really gotten quite conservative
> about them, just because of unintended and unforeseen
> consequences.

Right, and I think that is quite proper.  But you are on your
fifth major version and, if my quick count is correct, 5.1 is
your twelfth release.  By contrast, the current work is the
first revision of IDNA, leading to what we presume will be the
second release.  I suggest that, had you and your colleagues
applied the kinds of criteria that you are now suggesting for
IDNA to the transition between Unicode 1.1 and 2.0 (your third
and fourth releases), Unicode would be significantly less
usable, and probably less used, today.

It seems to me that granting some flexibility about the types of
changes that are considered appropriate to the first full
revision, in order to get things right based on experience with
the initial version, is reasonable, just as it was with Unicode
1.x -> 2.0.


More information about the Idna-update mailing list