<div><font face="times new roman, serif"><div>Anne, </div><div><br></div><div>The development of IDNA2008 was a long, painful, and frustrating process, with a split between:</div><div><ul><li>people who were concerned with backwards compatibility and what would happen during a migration period (such as most representatives to the Unicode consortium, and <br>
</li><li>people who did not feel that it was a concern (such as John, the other authors, and most participants in the WG).<br></li></ul></div><div>The rough consensus of the WG was judged to be that backwards compatibility and migration were not concerns, and that's what went into idna2008. </div>
<div><br></div><div>Yet for companies like mine, compatibility is rather important; we need to ensure that URLs like <a href="http://xn--bb-eka.at">http://ÖBB.at</a> continue to work as people expect, and URLs like <a href="http://www.amt-golssener-land.de/">http://www.amt-golßener-land.de/</a> go to a single location, rather than (depending on the browsers), sometimes:</div>
<div><ul><li>sometimes their original pages (<a href="http://www.amt-golssener-land.de">http://www.amt-golssener-land.de</a>)</li><li>sometimes new pages (<a href="http://www.xn--amt-golener-land-mlb.de">http://www.xn--amt-golener-land-mlb.de</a>)<br>
</li></ul></div><div>Not wanting to repeat that long conversation (and wade through the typically <i>very</i> long messages on the topic), I might suggest your poking through the archives, such as searching:<br></div><div>
<br></div><div><a href="https://www.google.com/webhp?q=site:www.alvestrand.no%2Fpipermail%2Fidna-update+migration">https://www.google.com/webhp?q=site:www.alvestrand.no%2Fpipermail%2Fidna-update+migration</a></div><div><a href="https://www.google.com/webhp?q=site:www.alvestrand.no%2Fpipermail%2Fidna-update+backwards+compatiblity">https://www.google.com/webhp?q=site:www.alvestrand.no%2Fpipermail%2Fidna-update+backwards+compatiblity</a></div>
<div><br></div><div>For example:</div><div><br></div><div><a href="http://www.alvestrand.no/pipermail/idna-update/2011-October/007167.html">http://www.alvestrand.no/pipermail/idna-update/2011-October/007167.html</a></div>

</font></div>
<div class="gmail_extra"><br clear="all"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><a href="https://plus.google.com/114199149796022210033" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div>
</div><br>
<br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 10:08 AM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com" target="_blank">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
--On Thursday, November 15, 2012 08:28 -0800 Anne van Kesteren<br>
<div class="im"><<a href="mailto:annevk@annevk.nl">annevk@annevk.nl</a>> wrote:<br>
<br>
> What is an "IUser"? Also, what other than "a" (U+0061) would<br>
> "Ａ" (U+FF21) map to? Host names have been case-insensitive<br>
> from the start, the Turkish I is not going to change that.<br>
<br>
</div>Anne,<br>
<br>
Statements like "Host names have been case-insensitive from the<br>
start" are precisely where i18n design decisions start wandering<br>
into the swamp.  From the start, host names have been basic,<br>
undecorated, "Latin" characters, coded in [seven bit] ASCII and<br>
transmitted over the Internet with a leading zero on each octet.<br>
Worse, while the DNS (server) case-matching rules provide and<br>
support case-insensitive matching for ASCII, if one were to code<br>
UTF-8 or ISO 8859-1 (or ISO 8859-anything else) into the DNS,<br>
octets whose high bit is one are compared without any adjustment<br>
for case, i.e., case-sensitively.<br>
<br>
"A" is just an example, but the problem is that in some<br>
languages and locales, not only does "a" (U+0061) upper-case to<br>
"A" (U+0041), but so does "á" (U+00E1).  In other languages and<br>
locales, á upper-cases to "Á" (U+00C1) -- it just depends.<br>
And that makes it plausible that the lower case form of "A" can<br>
be either "á" or "a" and possibly some other things.<br>
<br>
If one must deal with "Ａ" (U+FF21) at all (and I think that is<br>
a UI matter, not a DNS or IDNA one), then it is pretty clear<br>
that it should be mapped to "A" (U+0041).  But that leaves the<br>
non-unique lower case issue above.<br>
<br>
It was precisely the above types of issues, their relationship<br>
to the mapping between A-labels and native character forms being<br>
non-unique, and the problems the latter caused that resulted in<br>
exclusion of mapping from the base IDNA2008 protocol.<br>
<br>
Note  that none of the above depends on either dotless-i or<br>
Jefsey's specialized perspective -- the problems are fairly<br>
general.<br>
<div class="im"><br>
> Also, the focus on end users over stability of URLs found in<br>
> markup in elsewhere feels like a distraction. Most users, for<br>
> better or worse, use a search engine these days to get to a<br>
> particular domain. They no longer enter addresses in the<br>
> address bar.<br>
<br>
</div>But this is exactly the problem.  Different parties are looking<br>
at the same symptoms and drawing different conclusions.  ICANN<br>
and its many constituencies and dependents, for example, appears<br>
to not believe the data.  If they did, the pursuit of "delegated<br>
variants" and other efforts to make the DNS do what search<br>
engines do far better (and with less trouble and risk) would be<br>
insane.<br>
<br>
But I think we disagree on the criteria for "stability of URLs".<br>
I spent part of my life working with identifiers in an<br>
information retrieval context.  That leads me to want to see<br>
identifiers --URLs included-- that are expressed in unique<br>
canonical form and to distrust aliases and alternate forms as<br>
just something else that can go wrong.  That principle applies<br>
to the identifiers themselves, not navigational aids to finding<br>
the identifiers or objects.    The same principle especially<br>
shows up in one piece of the URL puzzle: if the comparison rule<br>
is "exact string match", then two different URLs for an object<br>
are a problem.  If one wants really stable, useful, URLs and<br>
assumes that the mapping from what the user types to those URLs<br>
will be the province of search engines and other UI aids, then<br>
the URLs (or other identifiers for other protocols) one wants<br>
will have domain information expressed in canonical form -- for<br>
IDNs, A-labels -- and tail information expressed with as few<br>
variable forms as possible.<br>
<br>
>From that perspective, I don't see the things you are asking<br>
for/ doing as providing/ preserving URL stability at all.  It<br>
seems to me that what you are trying to preserve is the sloppy<br>
or "clever" behavior of some early HTML authors and their<br>
ability to be similarly sloppy or clever in the future.  Again<br>
from my perspective, there has never been a good reason to use a<br>
non-target form (i.e., Nameprep result under IDNA2003 or U-label<br>
form under IDNA2008) in a URL.  As proportionately more and more<br>
web pages are created with HTML-specific authoring tools (and<br>
fewer with the likes of vi or emacs), the argument for not<br>
limiting URLs to A-label form seems to diminish at at least the<br>
same rate.<br>
<br>
regards,<br>
   john<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br></div>