<html>
<body>
Mark,<br>
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.<br>
jfc<br><br>
At 20:58 15/02/2009, Mark Davis wrote:<br>
<blockquote type=cite class=cite cite="">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>
Mark<br><br>
<br>
On Sat, Feb 14, 2009 at 02:38, Cary Karp
<<a href="mailto:ck@nic.museum">ck@nic.museum</a>> wrote:<br>
<dl>
<dd>I'm a tad confused here.<br><br>
<dd>> 1. Any Local Mapping allowed (current situation in IDNA2008) -
*Very<br>
<dd>> bad.* *We foresee that in practice UTS 46 mappings would be used
to<br>
<dd>> maintain compatibility with IDNA2003. However, it could
also<br>
<dd>> encourage incompatible localized mappings, which would
cause<br>
<dd>> interoperability and security problems.*<br>
<dd>> * *<br>
<dd>> 2. No mapping allowed - *Very bad. And unenforceable*<br><br>
<dd>How can any process be aware of what has previously been done with
the<br>
<dd>data that is passed to it?<br><br>
<dd>How can the protocol that defines a process possibly either
proscribe<br>
<dd>or prescribe what happens before that process is invoked?<br><br>
<br><br>
<dd>> 3. Silent on mapping - *Bad*<br><br>
<dd>That's for sure!<br><br>
<dd>> *We foresee that in practice UTS 46 mappings would be used to
maintain<br>
<dd>> compatibility with **IDNA2003**. The danger here is the same as
for<br>
<dd>> #1; it is not quite as bad as mentioning local mapping
explicitly,<br>
<dd>> thereby implicitly encouraging it.*<br><br>
<dd>Sounds good, but what happens when some other segment of the
user<br>
<dd>community decides that it has a better understanding of its
local<br>
<dd>mapping requirements than is reflected in UTS 46, and prefers to<br>
<dd>implement its own codification of those requirements? What
happens<br>
<dd>when the way code points are treated in one such mapping collides
with<br>
<dd>the way those code points are handled in another? (And I don't
believe<br>
<dd>the recursive answer, "That's why we have decided to impose our
own<br>
<dd>notion of such things on everybody else", is
satisfactory.)<br><br>
<dd>From everything I've seen of the way IDNs are diffusing into the<br>
<dd>second- and lower levels of the DNS, and from all I've understood
of<br>
<dd>the discussion of the introduction of A-labeled TLDs into the root,
the<br>
<dd>wisest way to address the issue of mapping (and perhaps the only
sure<br>
<dd>way to avoid cultural quicksand turning into political dynamite)
would<br>
<dd>be through the narrative component of the protocol.<br><br>
<dd>That being said, if there really is some core set of mappings that
we<br>
<dd>all agree are vital, and is otherwise beyond contention -- not
just<br>
<dd>within our group, but to a high degree of surety in the broadest<br>
<dd>international perspective -- perhaps its elements could be
articulated<br>
<dd>in a manner similar to the one used to permit code points in
exception<br>
<dd>to the algorithmic output that generates the mainstay
repertoire?<br><br>
<dd>This might usefully brake perceived need for locally applied<br>
<dd>preprocessing but, again, I don't see how the protocol can
possibly<br>
<dd>preclude that alternative in anything even vaguely resembling an<br>
<dd>absolute sense. I do, however, see a good deal of damage that
might<br>
<dd>result if we assume that it can, and prepare it on that basis.<br>
<font color="#888888"><br>
<dd>/Cary<br>
</font><br>
</dl><br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>