Unicode position on local mapping

[Mark Davis]

Cary,

IDNA (2003) requires a mapping phase. I have seen no serious implementation
of IDNA that doesn't do that mapping phase as the spec requires, or that
tries to circumvent it and do additional mappings beforehand. So we have
plenty of evidence of how a general mapping would work if included in the
specification, and that it would be applied uniformally. After all,
browsers, emailers, search engines, IMers, etc. that deviate from that spec
would be faced with interoperability problems.

You say "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?"

This is all very handwavey - you need to spell out some examples what you
mean by a user community, how this would translate into technology, and why
it would not fragment the DNS system.

I'm guessing by user community that you don't mean, say, people who play
bridge, but rather something like "native speakers of a language", like
Northern Sami (se) [as opposed to Southern Sami (sma), Lule Sami (smj),
etc.]

Let's take that for the moment. First issue is who speaks for the Northern
Sami community, and decides what the mapping should be. In many cases, there
is no centralized, recognized authority (look at English, for example), or
there are multiple authorities that disagree.

But let's assume that there a single, widely recognized authority, and they
decide that unlike IDNA2003, Á should not map to à and not á. So they
publish that. What happens?

Well, in this case, probably nothing. Why you say "prefers to
implement its own codification of those requirements", the Northern Sami
user community is not going to implement all of its own browsers, emailers,
search engines, IMers, etc.

But let's suppose that Opera version 99 takes up the gauntlet. The first
issue is, how do they know when to use this local mapping? Do they test by
IP address, and figure that if they are in Northern Scandinavia they apply
this mapping? Or do they use the user's language setting? Or do they go by
domain name?

Skipping over that huge issue, let's suppose that they have some magic
heuristic for applying this local mapping. So they identify user X somehow
as belonging to the Northern Sami user community. And in that case, when
they run across href="Á.com" in a web page, they head off to a different
website than Firefox does, or than Opera version 98 does. And if user Y
sends user X an email containing "http://Á.com <http://xn--1ca.com>", X will
go to a different page than Y intended (if Y doesn't use the browser/version
or is not identified as Northern Sami). A message that is supposed to direct
someone to a banking site goes to a spoof site. And so on.

The end result, even if the many gaping implementation chasms could get
fleshed out in any kind of reasonable wayy, is pointless fragmentation --
interoperability and security problems -- across users, across versions, and
across programs.

Why would such fragmentation of the DNS be a good thing?

Mark


On Sat, Feb 14, 2009 at 02:38, Cary Karp <ck at nic.museum> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090215/3f6aa715/attachment.htm