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

[Erik van der Poel]

I largely agree, but you said something about Jamos the other day,
that I'm a bit concerned about. You seemed to say that we should
prohibit those in the _input_ to the mapping function, but as far as I
know, we are still advocating NFC during lookup, so I don't know where
that leaves us with respect to Jamos.

Erik

On Wed, Apr 1, 2009 at 12:51 PM, John C Klensin <klensin at jck.com> wrote:
>
>
> --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.
>
>    john
>
>