Q2: What mapping function should be used in a revised IDNA2008 specification?

John C Klensin klensin at jck.com
Wed Apr 1 21:51:19 CEST 2009

--On Wednesday, April 01, 2009 08:29 -0700 Erik van der Poel
<erikv at google.com> wrote:

> One downside is that
> implementations would need separate tables or routines for
> NFKC and IDNA.

We are, of course, there already.  While
NFKC(CaseFold(NFKC(string))) is a good predictor of the
Stringprep mappings, it is not an exact one, and IDNA2003
implementations already need separate tables for NFKC and IDNA.

That is where arguments about complexity get complicated.
IDNA2008, even with contextual rules, is arguably less complex
than IDNA2003 precisely because, other than that handful of
characters, the tables are smaller and the interpretation of an
entry in those tables is "valid" or "not".  By contrast,
IDNA2003 requires a table that is nearly the size of Unicode
with mapping actions for many characters.   And, of course, a
transition strategy that preserves full functionality for all
labels that were valid under IDNA2003 means that one has to
support both, which is the most complex option possible.


More information about the Idna-update mailing list