Unicode position on local mapping

[Cary Karp]

I'm a tad confused here.

> 1. Any Local Mapping allowed (current situation in IDNA2008) - *Very
> bad.* *We foresee that in practice UTS 46 mappings would be used to
> maintain compatibility with IDNA2003. However, it could also
> encourage incompatible localized mappings, which would cause
> interoperability and security problems.*
> * *
> 2. No mapping allowed - *Very bad. And unenforceable*

How can any process be aware of what has previously been done with the
data that is passed to it?

How can the protocol that defines a process possibly either proscribe
or prescribe what happens before that process is invoked?

> 3. Silent on mapping - *Bad*

That's for sure! 

> *We foresee that in practice UTS 46 mappings would be used to maintain
> compatibility with **IDNA2003**. The danger here is the same as for
> #1; it is not quite as bad as mentioning local mapping explicitly,
> thereby implicitly encouraging it.*

Sounds good, but what happens when some other segment of the user
community decides that it has a better understanding of its local
mapping requirements than is reflected in UTS 46, and prefers to
implement its own codification of those requirements? What happens
when the way code points are treated in one such mapping collides with
the way those code points are handled in another? (And I don't believe
the recursive answer, "That's why we have decided to impose our own
notion of such things on everybody else", is satisfactory.)

From everything I've seen of the way IDNs are diffusing into the
second- and lower levels of the DNS, and from all I've understood of
the discussion of the introduction of A-labeled TLDs into the root, the
wisest way to address the issue of mapping (and perhaps the only sure
way to avoid cultural quicksand turning into political dynamite) would
be through the narrative component of the protocol.

That being said, if there really is some core set of mappings that we
all agree are vital, and is otherwise beyond contention -- not just
within our group, but to a high degree of surety in the broadest
international perspective -- perhaps its elements could be articulated
in a manner similar to the one used to permit code points in exception
to the algorithmic output that generates the mainstay repertoire?

This might usefully brake perceived need for locally applied
preprocessing but, again, I don't see how the protocol can possibly
preclude that alternative in anything even vaguely resembling an
absolute sense. I do, however, see a good deal of damage that might
result if we assume that it can, and prepare it on that basis.

/Cary