...<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;">My conclusions are:<br>
<br>
(1) Looking up unregistered code points is untenable because it<br>
makes moving to future versions of Unicode impossible. That<br>
conclusion is already reflected in IDNA200X, but IDNA2003<br>
requires such lookups.</blockquote><div><br>I disagree. While I'm willing to live with the John, Harald, and Patrik's decision to disallow the resolution with unassigned characters -- just so we can get this thing out the door -- we should not be basing any <i>other</i> decisions on thinking that it is "untenable".<br>
<br>Consider an character X that was unassigned in Unicode 5.1, but assigned in Unicode 6.0, and see what happens. Let's suppose that a U5.1 client sends out "aXc.com" ("a" and "c" are some particular strings, not the literal U+0061 and U+0063). Before the registry upgrades to U6.0, it will fail, as expected -- it wasn't (and couldn't have been) registered. <br>
<br>So let's look at the case where the registry has upgraded to U6.0. There are a small number of cases, and I don't see that *any* of them cause a problem.<br><br>Cases:<br><ol><li>X is illegal according to IDNA200X rules under U6.0. The registry can't register it, so it won't work. <b>Not a problem.</b><br>
</li><li>X is legal and unaffected by normalization<i>. <b>This is true of the vast majority of characters. </b></i>Then if the registry adds "aXc.com", then the old client will work, as expected. <b>Not a problem -- in fact, a positive benefit.</b><br>
</li><li>X is legal but affected by normalization -- but not in the context of "a...c". <i>This is true of the vast majority of those few characters remaining from case #2.</i> Then if the registry adds "aXc.com", then the old resolver will work. <b>Not a problem -- in fact, a positive benefit.</b></li>
<li>X is legal, and affected by normalization, in the context of "a...c". For example, suppose that string a ends with a non-spacing mark that reorders with X in NFC. In that case, "aXc.com" would not be legal, and could not be registered. <b>So even in this rare case, not a problem.<br>
</b></li></ol>John, if you think this situation is untenable, which of the above cases causes a problem, and exactly what would that problem be?<br><br>Mark<br><br></div><br></div>