Unicode position on local mapping

JFC Morfin jefsey at jefsey.com
Sun Feb 15 00:58:35 CET 2009


At 11:38 14/02/2009, Cary Karp wrote:
>I'm a tad confused here.

+1
Or perhap's when Marks says "protocols" he means architecture + 
protocol; i.e. a pure IETF Unicode independent way of addressing the 
issue? This however is not IDNA.
jfc

 > 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
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update



More information about the Idna-update mailing list