Unicode position on local mapping
JFC Morfin
jefsey at jefsey.com
Mon Feb 16 11:20:52 CET 2009
Mark,
let say that the French ccTLD decides a position on "école.fr" and
"ecole.fr" being the same domain name or not due to the case folding issue.
jfc
At 20:58 15/02/2009, Mark Davis wrote:
>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://xn--1ca.com>http://Ã.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
><<mailto:ck at nic.museum>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
>
>
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090216/12c52eec/attachment-0001.htm
More information about the Idna-update
mailing list