We have had a lot of productive discussion lately. Here is my take on your questions of 6 days ago, with "..." elisions so as to get at the core questions.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(i) We ban registration-side mapping in the protocol and<br>
discourage any local mapping on that side. ...</blockquote><div><br>I agree.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(ii) We make it clear (if it isn't already) that, in cases ... in which perceived relationships among label strings are important, it is the responsibility of the relevant registry to cope ....</blockquote><div><br>
I'm not sure what this means. I'm guessing you mean policies like bundling and blocking; if so, I agree.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(iii) We tell folks on the lookup side that, if a label in<br>
native-character form is invalid under IDNA2008 but valid under<br>
IDNA2003, they SHOULD apply the IDNA2003 mappings and look the<br>
thing up. Note that this implies two tests but only one lookup<br>
in the DNS. ...</blockquote><div><br>If we made that a MUST, I'd be happy with it. If it is not a MUST, then we can always have two kinds of implementations, which will inevitably cause some interoperability problems.<br>
<br><div style="margin-left: 40px;">Even somewhat better would be to have updated mappings a la TR46. Some figures:<br></div><ul style="margin-left: 40px;"><li>There are about 5.5K characters <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B:age=5.1:%5D-%5B:age=3.2:%5D%5D">added after Unicode 3.2</a>. (Note also that 5.2 is due out this fall, and will add more).</li>
<li>Of these 433 have <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B:age=5.1:%5D-%5B:age=3.2:%5D-%5B%5B:isLowercase:%5D-%5B:nfkcqc=n:%5D%5D%5D">NFKC+CaseFold mappings</a>.</li></ul><div style="margin-left: 40px;">
While a number of these are archaic, some are not. It would be inconsistent for a language using new and old characters for some characters be mapped and others not. This would especially be the case for uppercases: illustrating this with ASCII, for "Abc" to map to "abc", but for "Bcd" to just fail.<br>
</div><br>However, bottom line, the main reasons for the mappings are interoperability, so it is far, far important for us to maintain the 2003 mappings than to extend them to new characters.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(iv) For the four "changed interpretation" cases, we make it<br>
clear that the IDNA2008 interpretation is the important one and<br>
that registries have a lot of responsibility here. However,<br>
if an application is in a position to deliver two different<br>
answers to the user, then it MAY reasonably do both lookups and<br>
then do whatever with them seems appropriate (obviously, a "did<br>
you really mean?" dialogue would be one such option).</blockquote><div><br>Agreed as well. That, I think, is the only option I've heard for handling for whatever characters end up in IDNA 2008 with changed interpretations that would help mitigate the security problems. <br>
<br>The specified order of lookup will be important. The did you mean option could be recommended for user-facing code. That isn't, of course, much use for a lot of software like search engines, but for UIs could be useful.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Does that help?<br>
<br>
john<br>
<br>
<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>