<br><br><div class="gmail_quote">On Sun, Apr 27, 2008 at 11:37 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">On 28 apr 2008, at 04.04, Mark Davis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If historic scripts are to be excluded, the up-to-date list recommended by<br>
the consortium for U5.1 is at<br>
<br>
<a href="http://www.unicode.org/reports/tr31/#Specific_Character_Adjustments" target="_blank">http://www.unicode.org/reports/tr31/#Specific_Character_Adjustments</a><br>
</blockquote>
<br></div>
As someone said already, in todays algorithm, we block things based on blocks, not scripts. If people want the selection on scripts back, fine, but that is something I want consensus on (as well).</blockquote><div><br>I'm not arguing for that; I was just pointing out where to get a list that was relevant to someone else's thread. <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"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
(BTW, I'm strongly against restoring MAYBE, for a number of reasons already<br>
discussed. Haven't heard back from Patrik as to why, though, we couldn't in<br>
exceptional circumstances move characters from DISALLOWED. If that is<br>
allowed, then it would be reasonable to exclude historic scripts, since even<br>
if there were an out-of-the-blue revival, they could be handled.)<br>
</blockquote>
<br></div>
I though I explained and that I had not heard back from you :-)</blockquote><div><br>I seen no response from you to my message of:<br><br><table class="BwDhwd"><tbody><tr class="UszGxc"><td class="UdFq5e"><span class="HcCDpe">from</span></td>
<td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img class="Jx04sb QrVm3d" id="upi" name="upi" src="images/cleardot.gif" height="16" width="16"></span><span class="EP8xU" style="color: rgb(0, 104, 28);">Mark Davis</span> <span class="lDACoc"><<a href="mailto:mark.davis@icu-project.org">mark.davis@icu-project.org</a>></span></span></td>
</tr><tr><td colspan="2" class="UdFq5e"><span class="HcCDpe">to</span></td><td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img class="Jx04sb QrVm3d" id="upi" name="upi" src="images/cleardot.gif" height="16" width="16"></span>Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>>,<br>
</span></td></tr><tr><td colspan="2" class="UdFq5e"><span class="HcCDpe">cc</span></td><td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img class="Jx04sb QrVm3d" id="upi" name="upi" src="images/cleardot.gif" height="16" width="16"></span>Martin Duerst <<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>>,<br>
<span class="JDpiNd"><img class="Jx04sb QrVm3d" id="upi" name="upi" src="images/cleardot.gif" height="16" width="16"></span><a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>,<br><span class="JDpiNd"><img class="Jx04sb QrVm3d" id="upi" name="upi" src="images/cleardot.gif" height="16" width="16"></span>Andrew Sullivan <<a href="mailto:ajs@commandprompt.com">ajs@commandprompt.com</a>>,<br>
</span></td></tr><tr><td colspan="2" class="UdFq5e"><span class="HcCDpe">date</span></td><td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img src="images/cleardot.gif" height="16" width="16"></span>Tue, Apr 22, 2008 at 10:24 PM</span></td>
</tr><tr><td colspan="2" class="UdFq5e"><span class="HcCDpe">subject</span></td><td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img src="images/cleardot.gif" height="16" width="16"></span>Re: Stability of valid IDN labels</span></td>
</tr><tr><td colspan="2" class="UdFq5e"><span class="HcCDpe">mailed-by</span></td><td colspan="2" class="sA2K5"><span class="HcCDpe"><span class="JDpiNd"><img src="images/cleardot.gif" height="16" width="16"></span><a href="http://gmail.com">gmail.com</a></span></td>
</tr></tbody></table><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>
<br>
Reason is that applications that block those codepoints will not let the codepoints be resolved. So starting using those codepoints will create problems.</blockquote><div><br>That is circular, and doesn't address my question. Let me repeat my questions again, since somehow it is not getting through in the email. Let me call -- just for discussion! -- <b>IDNA 2008-U5.2</b> the version of IDNA that uses Unicode 5.2 as a base. I'll try to change the wording to be clearer.<br>
<br><div style="margin-left: 40px;"><b>I'll give a concrete case. Let's suppose that in IDNA 2008-U5.2</b><b>, the IETF (through some mechanism) changes PVALID to include MODIFIER LETTER <span>RHOTIC</span>
HOOK (and removed from DISALLOWED). Unicode 5.2 also adds a new assigned letter, U+xxxx IMPORTANT THAI CHARACTER, which is thus automatically added to IDNA 2008-U5.2 as PVALID (it was UNASSIGNED in </b><b>IDNA 2008-U5.1)</b><b>.</b></div>
<ul style="margin-left: 40px;"><li><b>Application A implements </b><b>IDNA 2008-U5.1</b><b>, and it is not updated for 10 years. (Patrik's case)<br> </b></li><li><b>Application B updates to </b><b>IDNA 2008-U5.2</b><b>.</b></li>
</ul><div style="margin-left: 40px;"><b>Application A will disallow some perfectly valid </b><b>IDNA 2008-U5.2</b><b> labels;
labels that Application B allows. That is, it will disallow a label X containing RHOTIC
HOOK and it will disallow a label Y containing IMPORTANT THAI CHARACTER. Application B will allow both of the labels.<br><br>What advantage is it to functionally distinguish between these
two characters?<br>Why is it vital for Application A to do so, since it will disallow both X and Y anyway?</b><br></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
This was exactly why we had MAYBE NOT category.</blockquote><div><br>This is quite different from the MAYBE NOT category. <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>
<br>
And the reason why we have the backward compatibility category (so that the algorithm can be kept in sync with the Unicode data).<br>
<br>
That said (which we said in earlier discussions) every time RFCs are updated a decision has to be made regarding the change, and the reason why etc etc.</blockquote><div><br>What do you mean by "the change"? I think part of the reason that we appear to be talking past one another is that we're not using the same terminology or perhaps model. It sounds like what you are saying here is that DISALLOWED *can* be changed if another RFC is issued that obsoletes IDNA2008, adding (for example) RHOTIC
HOOK to the exception table as PVALID. Do you mean that, or am I misinterpreting?<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>
Patrik</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Mark<br>
<br>
On Sun, Apr 27, 2008 at 6:19 PM, Paul Hoffman <<a href="mailto:phoffman@imc.org" target="_blank">phoffman@imc.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
At 2:24 AM +0200 4/28/08, Frank Ellermann wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
In Unicode 5.1 Phaistos Disc, Carian, Lycian, and Lydian were added.<br>
<br>
</blockquote>
<br>
Ah. Where? I don't see that on <<br>
<a href="http://www.unicode.org/versions/Unicode5.1.0/" target="_blank">http://www.unicode.org/versions/Unicode5.1.0/</a>>.<br>
<br>
For IDNAbis the list could be extended with say Glagolitic, Deseret,<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
and Shavian.<br>
<br>
</blockquote>
<br>
If we want to hand-pick them, yes. I proposed that we only use what The<br>
Unicode Consortium has decided.<br>
<br>
But that requires great care, excluding Osmanyan could<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
backfire if a future country in the former Somalia adopts it again.<br>
<br>
</blockquote>
<br>
...an even better reason not to hand-pick.<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>
_______________________________________________<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>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark