Cary,<br><br>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.<br>
<br>You say "what happens when some other segment of the user<br>
community decides that it has a better understanding of its local<br>
mapping requirements than is reflected in UTS 46, and prefers to<br>
implement its own codification of those requirements?"<br><br>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.<br>
<br>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.]<br>
<br>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.<br>
<br>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?<br><br>Well, in this case, probably nothing. Why you say "prefers to<br>
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.<br><br>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? <br>
<br>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 "<a href="http://xn--1ca.com">http://Á.com</a>", 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.<br>
<br>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.<br>
<br>Why would such fragmentation of the DNS be a good thing?<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Sat, Feb 14, 2009 at 02:38, Cary Karp <span dir="ltr"><<a href="mailto:ck@nic.museum" target="_blank">ck@nic.museum</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm a tad confused here.<br>
<div><br>
> 1. Any Local Mapping allowed (current situation in IDNA2008) - *Very<br>
> bad.* *We foresee that in practice UTS 46 mappings would be used to<br>
> maintain compatibility with IDNA2003. However, it could also<br>
> encourage incompatible localized mappings, which would cause<br>
> interoperability and security problems.*<br>
> * *<br>
</div>> 2. No mapping allowed - *Very bad. And unenforceable*<br>
<br>
How can any process be aware of what has previously been done with the<br>
data that is passed to it?<br>
<br>
How can the protocol that defines a process possibly either proscribe<br>
or prescribe what happens before that process is invoked?<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
> 3. Silent on mapping - *Bad*<br>
<br>
That's for sure!<br>
<br>
> *We foresee that in practice UTS 46 mappings would be used to maintain<br>
<div>> compatibility with **IDNA2003**. The danger here is the same as for<br>
> #1; it is not quite as bad as mentioning local mapping explicitly,<br>
</div>> thereby implicitly encouraging it.*<br>
<br>
Sounds good, but what happens when some other segment of the user<br>
community decides that it has a better understanding of its local<br>
mapping requirements than is reflected in UTS 46, and prefers to<br>
implement its own codification of those requirements? What happens<br>
when the way code points are treated in one such mapping collides with<br>
the way those code points are handled in another? (And I don't believe<br>
the recursive answer, "That's why we have decided to impose our own<br>
notion of such things on everybody else", is satisfactory.)<br>
<br>