<font size="2">For us to come to a conclusion about the contents of IDNNever, we first have
to agree on the usage model, otherwise we'll just be talking about different
things. Here are the differences, as far as I can see them.</font>
<p><font size="2">All of the models provide for a partition of Unicode code points into 4
classes: IDNPermitted, IDNNever, IDNPending, and Unassigned. The key difference
is in the migration path, so we have to consider the migration implications.
Let's take the following scenario.</font></p>
<ol><li><font size="2">the registrar is on the version of IDNAbis using Unicode 5.1</font></li><li><font size="2">the user gets a document containing ... href="<a href="http://axb.com/">http://aXb.com</a>"...,
where X is a 5.1 IDNPermitted character, and clicks on the link.</font></li><li><font size="2">the client software is on the version of IDNAbis using
Unicode 5.0</font></li></ol>
<p><font size="2">In all of these models, the only property the registrar needs to have is IDNPermitted. The other classes would only have an impact on the client
side; it depends on the model whether or not distinctions between them are
operationally necessary.</font></p>
<p><font size="2"><b>A. Strict Model</b></font></p>
<table id="table1" border="1" width="100%">
<tbody><tr>
<td><font size="2"> </font></td>
<td><font size="2">IDNPermitted</font></td>
<td><font size="2">IDNNever</font></td>
<td><font size="2">IDNPending</font></td>
<td><font size="2">Unassigned</font></td>
</tr>
<tr>
<td><font size="2">Allow in client</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td bgcolor="#ffff00"><font size="2">N</font></td>
<td bgcolor="#ffff00"><font size="2">N</font></td>
</tr>
<tr>
<td><font size="2">Allow in registrar</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
</tr>
</tbody></table>
<p><font size="2">This one is the simplest model, but has a significant migration problem. The
user will not be able to get to the desired web page, since the URL will be
refused by the client software. Thus the user will be able to get to the web
page:</font></p>
<ol><li><font size="2">If the client is upgraded to 5.1</font></li></ol>
<p><font size="2"><b>B. Minimal Model</b></font></p>
<table id="table3" border="1" width="100%">
<tbody><tr>
<td><font size="2"> </font></td>
<td><font size="2">IDNPermitted</font></td>
<td><font size="2">IDNNever</font></td>
<td><font size="2">IDNPending</font></td>
<td><font size="2">Unassigned</font></td>
</tr>
<tr>
<td><font size="2">Allow in client</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td bgcolor="#ffff00"><font size="2">Y</font></td>
<td bgcolor="#ffff00"><font size="2">N</font></td>
</tr>
<tr>
<td><font size="2">Allow in registrar</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
</tr>
</tbody></table>
<p><font size="2">This model alleviates the migration somewhat less. The user will be able to
get to the web page:</font></p>
<ol><li><font size="2">If the client is upgraded to 5.1, or</font></li><li><font size="2">If X was assigned in 5.0</font></li></ol>
<p><font size="2"><b>C. Maximal Model</b></font></p>
<table id="table4" border="1" width="100%">
<tbody><tr>
<td><font size="2"> </font></td>
<td><font size="2">IDNPermitted</font></td>
<td><font size="2">IDNNever</font></td>
<td><font size="2">IDNPending</font></td>
<td><font size="2">Unassigned</font></td>
</tr>
<tr>
<td><font size="2">Allow in client</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td bgcolor="#ffff00"><font size="2">Y</font></td>
<td bgcolor="#ffff00"><font size="2">Y</font></td>
</tr>
<tr>
<td><font size="2">Allow in registrar</font></td>
<td><font size="2">Y</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
<td><font size="2">N</font></td>
</tr>
</tbody></table>
<p><font size="2">This model alleviates the migration more. The user will be able to get to the
web page:</font></p>
<ol><li><font size="2">If the client is upgraded to 5.1, or</font></li><li><font size="2">If X was assigned in 5.0, or</font></li><li><font size="2">If X was unassigned in 5.0, but <a href="http://axb.com/">aXb</a> has the
correct IDNAbis output form (eg is normalized, lowercase,...)</font></li></ol>
<p><font size="2">Thus the user can get to the web page if the page author uses the output
form; if the scenario were the user typing/pasting into the address bar, then
the requirement would be the same: that the typing is normalized and lowercase.
Given the types of characters slated for encoding, it would be extremely rare
that typing would produce an X that doesn't work, but it is not absolutely
guaranteed.</font></p>
<p><font size="2">Some people think that not tolerable to have <a href="http://axb.com/">aXb</a>
work if it is in output form on 5.0, but not work if it is in input form; and
then work on 5.1 in either form. I don't quite understand the rationale for
that, so I'll look forward to an exposition.</font></p>
<p><font size="2">Mark<br></font></p><div><font size="2"><span class="gmail_quote">On 2/11/07, <b class="gmail_sendername">Patrik Fältström</b> <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>> wrote:</span>
</font><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font size="2">I think one can say that from an IETF perspective, the question is<br>
whether one should allow codepoints in the Unicode table that is of<br>one or more of the following General Categories should be allowed in<br>the U-label as defined by the document edited by John:<br><br>gc ; Sc ; Currency_Symbol
<br>gc ; Sk ; Modifier_Symbol<br>gc ; Sm ; Math_Symbol<br>gc ; So ; Other_Symbol<br><br>What John says is that we who look at this problem so far have not<br>seen enough evidence that these classes really are needed so that
<br>they should be included. We are using an inclusion based algorithm<br>this time.<br><br>What it a special General Category you where thinking of Avri?<br><br> Patrik<br><br>______________________________</font><font size="2">
_________________<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">http://www.alvestrand.no</a></font><font size="2">/mailman/listinfo/idna-update
<br></font></blockquote></div><font size="2"><br><br clear="all"><br>-- <br>Mark
</font>