You misunderstand: I'm not talking about a change by the Unicode consortium. Let me try to be clearer: I'm talking about the version of *IDNA*. What I said was:<br><br>"Let's suppose that IDNA 2008 is issued based on Unicode 5.1"<br>
<br>vs<br><br>"and that in the version [of IDNA 2008 data] corresponding to U5.2" - that is, in the version of the IDNA data that correspond to Unicode 5.2.<br><br>So these are both referring to versions of IDNA data, not Unicode data, and considering what would happen if we (in this committee, not Unicode) exceptionally allow characters to change status, AND it happens that the IANA committee or whoever decides changes to the context/exception tables adds MODIFIER LETTER RHOTIC HOOK to PVALID, removing it from DISALLOWED.<br>
<br>The rest of the message is trying to consider what the consequences would be.<br><br>Is it clearer now what I'm saying?<br><br>Mark<br><br><br><div class="gmail_quote">On Sun, Apr 27, 2008 at 11:44 PM, Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>> 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"><br>
On 28 apr 2008, at 06.36, Mark Davis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'll give a concrete case. Let's suppose that IDNA 2008 is issued based on<br>
Unicode 5.1, and that in the version corresponding to U5.2, PVALID were<br>
updated to include MODIFIER LETTER RHOTIC HOOK (and it was removed from<br>
DISALLOWED).<br>
</blockquote>
<br></div>
If that change is made in Unicode between 5.1 and 5.2, then from my personal point of view, then Unicode Consortium is not keeping the level on promise regarding stability that I hope they do.<br>
<br>
But if that change has to be made by Unicode Consortium between 5.1 and 5.2, then the tables document should be updated in sync with the deployment of Unicode 5.2, and I think the codepoint should be added to the backward compatibility list as DISALLOWED overriding the change made in Unicode Consortium.<br>
<br>
But, of course, when the tables RFC is overridden by a new one, then of course a decision can be made by the IETF to stay in sync with Unicode Consortium and allow a backward incompatible change to the algorithm.<br>
<br>
A big, hard decision. Very very very difficult decision to make given the implications in the DNS.<br>
<br>
I do know though UTC is very very aware of the implications of making incompatible changes, including legal implications regarding registrations in the DNS. Because we have had this discussion before.<br><font color="#888888">
<br>
Patrik<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mark