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

[John C Klensin]

FWIW, I agree with the sets of comments in both of the  messages
cited below...

One other observation, just to avoid sending an extra message.
I really hope that, in whatever mapping we decide is appropriate
(and whether we put it), we can avoid getting involved with the
"maps to nothing/ default ignorable" function.   While I hope,
as I trust everyone else does, that we never run into the kind
of disastrous situation that would cause us to move a character
from DISALLOWED to PVALID (or CONTEXTx) somewhere down the line,
I think that one of the things we have learned from the ZWJ/ZWNJ
situation is that the cases in which a character was discarded,
leaving us with no clue at to what was intended to be in a
registration, is even worse and therefore to be avoided in the
interest of general prudence.

    john


--On Thursday, April 02, 2009 09:53 -0700 Erik van der Poel
<erikv at google.com> wrote:

> IDNA2008
> is a much more careful effort, with detailed dissection, as
> you can see in the Table draft. We should apply similar care
> to the "mapping" table.
> 
> I suggest that we come up with principles, that we then apply
> to the question of mapping. For example, the reason for
> lower-casing non-ASCII letters is to compensate for the lack
> of matching on the server side. The reason for mapping
> full-width Latin to normal is because it is easy to type those
>...

--On Thursday, April 02, 2009 10:50 -0700 Erik van der Poel
<erikv at google.com> wrote:

> It may not be necessary to do character-by-character analysis
> of NFKC. We may be able to select a small number of the NFKC
> tags:
> 
> <font>  	A font variant (e.g. a blackletter form).
> <noBreak>  	A no-break version of a space or hyphen.
> <initial>  	An initial presentation form (Arabic).
>...