If anything can happen if the RFC is updated, then we absolutely cannot promise people that DISALLOWED will never change in the future -- that would just lead people down a garden path.<br><br>But I would far rather that we design a mechanism and process that allows us to avoid such disruptions.<br>
<br>Mark<br><br><div class="gmail_quote">On Mon, Apr 28, 2008 at 12:31 AM, 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">On 28 apr 2008, at 08.55, Mark Davis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So these are both referring to versions of IDNA data, not Unicode data, and<br>
considering what would happen if we (in this committee, not Unicode)<br>
exceptionally allow characters to change status, AND it happens that the<br>
IANA committee or whoever decides changes to the context/exception tables<br>
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<br>
be.<br>
<br>
Is it clearer now what I'm saying?<br>
</blockquote>
<br></div>
Yes, I was confused when you talked about 5.1 and 5.2 which to me reference Unicode versions.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
"Let's suppose that IDNA 2008 is issued based on Unicode 5.1"<br>
</blockquote>
<br></div>
IDNA2008 is not based on Unicode 5.1. It is defining an algorithm that is to be applied to any version of Unicode. The table is non-normative. So a codepoint that is assigned DISALLOWED will not move from DISALLOWED if not one of three things happens:<br>
<br>
- UTC changes the data in the Unicode tables<br>
- A codepoint is added to the exceptions table<br>
- The algorithm is changed<br>
<br>
You say the first is out. Good.<br>
<br>
My personal view is that as we do not have MAYBE, things should _NEVER_ move from DISALLOWED or ALWAYS. Same reasons as always. Due to changes in ability for registration, requirement for sunrise, risk for applications to have the domain names no longer be accessible (or not able to access newly registered domain names) etc.<br>
<br>
As it is now, my view is that the change that is "ok" is move from UNASSIGNED to one of the other categories.<br>
<br>
But, of course changes like these can be made when the RFCs are updated. And when an RFC is updated, anything can happen.<br><font color="#888888">
<br>
Patrik<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mark