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