The original motivation for the mapping (in IDNA2003) was to make IDNs work like regular domain names, regarding case (and similar kinds of variants when extended to Unicode). It has nothing to do with "localization".<div>
<br></div><div>That is, with regular domain names, it doesn't matter which of the following are used:</div><div><ul><li><a href="http://bruder.de">http://bruder.de</a><br></li><li><a href="http://Bruder.de">http://Bruder.de</a><br>
</li></ul></div><div>The goal was to duplicate that behavior with IDNs, so that it wouldn't matter which of the following was used:</div><div><div><ul><li><a href="http://xn--brder-lva.de">http://brüder.de</a><br></li>
<li><a href="http://xn--brder-lva.de">http://Brüder.de</a></li></ul></div></div><div>Note that this is not a UI matter: IRIs appear not only in browser address bars, but also in email bodies, IMs, and so on. It is generally understood at the W3C, for example, that all attributes that take URLs should take full IRIs, not punycoded-URIs, so for example SVG, MathML, XLink, XML, etc, all take IRIs now, as does HTML5.</div>
<div><br></div><div>I think the motivation for "local mapping" in IDNA2008 is two-fold. Some of us need to maintain compatibility with IDNA2003. Others want to have special mappings for Turkish. (Personally, I think the latter makes for a nasty security and interoperability problem). I haven't heard any case but Turkish cited as an example of why someone would want a "localization" mapping.</div>
<div><br></div><div>Mark<br>
<br><br><div class="gmail_quote">On Mon, Dec 8, 2008 at 07:02, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Sun, Dec 07, 2008 at 04:27:09PM +0900, Martin Duerst wrote:<br>
> input conversions. For input conversions, the appopriate solution,<br>
> if any, is to add mapping to the protocol, but we (or whoever)<br>
> decided earlier on that mapping wouldn't be part of the protocol.<br>
<br>
</div>My impression of why we decided to take mapping out of the protocol,<br>
however, is that mapping is basically about localization. Since it is<br>
impossible to do localization at a global level, it should not be done<br>
at the protocol level but should instead be handled as close to the<br>
end as possible. At least, that's my impression of the reasoning<br>
behind the change.<br>
<br>
Now, one important premise in favour of the contextual rule is, I<br>
think, that this digit case is a really unusual one. If we accept<br>
that this is a very unusual case, and therefore that we're willing to<br>
put warts on the protocol that we otherwise aren't willing to add (all<br>
the while chanting, "No precedent, no precedent," I guess) then is<br>
this a case where we ought to add mapping to the protocol even though<br>
we otherwise have a principle that no mapping is allowed/required? (I<br>
have no opinion about this at the moment. I'm just asking.)<br>
<div class="Ih2E3d"><br>
A<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a><br>
Shinkuro, Inc.<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">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>