That is, in fact, the current outcome, because of two issues:<br><ol><li>There are 4 characters that are valid in both IDNA2003 and IDNA2008, but will direct to to different IP addresses. So if you send a friend a URL, he could end up going to a different site, if you have different browsers or different browser versions.</li>
<li>There is a proposal to add a mapping to IDNAbis that would be &quot;UI only&quot;, and optional. This is to handle user-expected variant differences: case, width,... That would also end up with problems with &quot;bus-ability&quot; in that whether a URL gets mapped is left up to the user-agent&#39;s choice, and what it thinks qualifies as &quot;UI&quot;, and even whether the mapping is changed (the mapping is a SHOULD). And there is no current requirement that the mapping be compatible with IDNA2003, so we get the same problem as #1.<br>
</li></ol>My opinion:<br><br>This is a rather bad situation -- for interoperability and security, let alone the user experience -- but that people in this group just don&#39;t realize it yet because they haven&#39;t gotten enough feedback from people who are concerned with interoperability and security. In particular, I believe that:<br>
<ol><li>We should have differences from the current state (IDNA2003) that cause a URL to go to a different site *only* if there is overwhelming justification and little negative impact.</li><ol><li>There is convincing evidence that this divergence is
necessary for two characters: ZWJ, and ZWNJ. Fortunately
these are extremely low frequency characters in current URLs within web pages, so the negative impact is quite limited.<br></li><li>There is not overwhelming justification for the two others: es-zett
(sharp S) and final sigma. As a matter of fact, the German NIC has come
out against the former. We do not have enough involvement from the Greek community to have any real case for the latter. And these are extremely frequent characters in the respective language communities.<br></li></ol><li>
We should have a mandatory mapping applied to all lookup (whether &quot;UI&quot; or not &quot;UI&quot;), whereby for any cases where IDNA2003 also maps, they must have the same result. Failing that, we should not provide any mapping in IDNA.<br>
</li></ol>Mark<br>
<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 13:03, Gervase Markham <span dir="ltr">&lt;<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>&gt;</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 must confess that I&#39;ve not had time recently to follow carefully the<br>
discussions about mappings. If that means that some people consign this<br>
message to the bit bucket, so be it.<br>
<br>
At the moment, standard domain names have what I&#39;ll call &quot;bus-ability&quot; -<br>
that is, if you see them in an advert on the side of a bus, you can<br>
write them down, type them into any web browser or other domain<br>
name-using client later, and you&#39;ll end up at the place intended by the<br>
creator of the advertisement. IDN domain names under the current version<br>
of IDN have, as far as I understand it, pretty much the same<br>
&quot;bus-ability&quot; property. In the IDN case, what the user types has to be<br>
first normalized, and then converted to punycode. The user in no way<br>
needs to know or care about this extra technical complexity. It just works.<br>
<br>
I would assert that this property is pretty key to keeping the web<br>
working in a sane and, importantly, secure manner. People convert domain<br>
names from print/voice/memory to computer and back all the time.<br>
<br>
If the standards were to change in such a way that it becomes quite<br>
legal and conforming that typing a set of characters into browser A<br>
takes you to website Q, but typing the same set into browser B takes you<br>
to website R, I would politely suggest that those who wrote the new<br>
standards had taken leave of their senses. This is a recipe for chaos.<br>
And phishing.<br>
<br>
This incredible outcome is not a serious possibility, is it?<br>
<br>
Gerv<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>
</blockquote></div><br>