<br><br><div class="gmail_quote">On Tue, Apr 22, 2008 at 12:15 PM, Patrik Fältström &lt;<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 22 apr 2008, at 20.33, Mark Davis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Patrick, I don&#39;t understand your reasoning.<br>
<br>
1. Why must we guarantee to developers that DISALLOWED never changes?<br>
</blockquote>
<br></div>
The other way around.<br>
<br>
We tell developers what codepoints are disallowed. They add those codepoints to be banned in their user interface. If then later we allow registration, we will have tons of applications out there that can not be used to access domain names that include that codepoint.</blockquote>
<div><br>That&#39;s circular. Banning codepoints in the UI because they are in DISALLOWED  -- in a product that isn&#39;t updated very often -- would only be a reasonable thing to do IF we disallow changes in DISALLOWED. If we don&#39;t, then it&#39;s a bad thing to do.<br>
<br>But if a product isn&#39;t updated very often, then *also* it won&#39;t pick up changes in UNASSIGNED characters moving to PVALID or DISALLOWED. And it also isn&#39;t going to catch changes in CONTEXT rules, and so on. In any event we&#39;d have your &quot;applications out there that can not be used to access domain names that include that codepoint&quot;. If a product is out of date -- and has no mechanism for getting the up-to-date tables -- it will only accept as valid those identifiers that qualify under whatever version of Unicode/IDN at the date it was released.<br>
<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;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="Ih2E3d">
changes, but why is it important for developers to be able to depend on it<br>
never changing? They can&#39;t depend on various changes over time: they can&#39;t<br>
depend on it not growing; they can&#39;t depend on UNASSIGNED not shrinking; and<br>
so on.<br>
<br>
For example, as an exception, suppose that<br></div>
U+02DE&lt;<a href="http://unicode.org/cldr/utility/character.jsp?a=02DE" target="_blank">http://unicode.org/cldr/utility/character.jsp?a=02DE</a>&gt;( ˞ )<div class="Ih2E3d"><br>
MODIFIER LETTER RHOTIC HOOK were to to be added in some future version<br>
to the exception list, because it was found to be needed for a particular<br>
African language. This would involve changing from DISALLOWED to ALLOWED.<br>
What would be the practical problem that this causes?<br>
<br>
We at Google, and I&#39;m sure others, have lots of code that depends on<br>
backward compatibility -- that once an identifier is valid, it stays valid.<br>
That allows us to always update to the latest validity checks on all<br>
identifiers, whether they are currently found or stored in databases. (A<br>
one-time hit is containable for IDNA2003, but ongoing changes would be<br>
untenable.)<br>
<br>
But anyone who stays current with the IDNA2003 specs always be expanding the<br>
valid identifiers.<br>
</div></blockquote>I agree that it is important for DISALLOWED to not have any but exceptional<br>
<br>
People use software without upgrading until their computers stop working. And that is 10+ years.</blockquote><div><br>Understood. But as above, their program just won&#39;t let them access labels that incorporate any changes in the tables, not just exceptional changes from DISALLOWED to PVALID.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

obsoleting IDNA200x and moving one character from DISALLOWED to PVALID?<br>
</blockquote>2. How can such a promise be guaranteed? What is to prevent IDNA2012 from<br>
<br></div>
Absolutely nothing of course. But when that choice is made, the people that make that decision must know that there will be software out there deployed until maybe 2022 or even longer that will not allow that codepoint in domain names.</blockquote>
<div><br>And some programs won&#39;t work with IDNA200x until then either, because they are stuck on IDNA2003.<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><font color="#888888">
<br>
 &nbsp; Patrik</font><div><div></div><div class="Wj3C7c"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Tue, Apr 22, 2008 at 12:38 AM, Patrik Fältström &lt;<a href="mailto:patrik@frobbit.se" target="_blank">patrik@frobbit.se</a>&gt;<br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 22 apr 2008, at 03.49, Martin Duerst wrote:<br>
<br>
What may happen<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
is that DISALLOWED is treated more closely to the way it is in<br>
IDNA2003: okay to query, but forbidden to register.<br>
<br>
</blockquote>
<br>
I object to any kind of idea like this.<br>
<br>
This makes it impossible for application developers to filter, and there<br>
is no way it is possible to control &quot;registration&quot; of DISALLOWED codepoints,<br>
and the latter is the reason why application developers have to filter out<br>
DISALLOWED codepoints completely.<br>
<br>
DISALLOWED is DISALLOWED. Forever. Period.<br>
<br>
&nbsp;Patrik<br>
<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">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>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Mark<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark