comments below.<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 01:06, Michael Everson <span dir="ltr">&lt;<a href="mailto:everson@evertype.com">everson@evertype.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oh my gods.<br>
<br>
Are we back HERE, at THIS decision?<br>
<div class="im"><br>
On 10 Mar 2009, at 05:18, Michel SUIGNARD wrote:<br>
<br>
&gt; +1 on Mark&#39;s message concerning confusability.<br>
&gt; I also think that script mixing within a label should be a client<br>
&gt; application decision, not dictated by protocol.<br>
<br>
</div>This is madness. I said this first when Cary started talking to me<br>
about this, when he was editing a draft when WG2 was at Sophia<br>
Antipolis.<br>
<br>
At that time, the idea that Cyrillic and Greek and Latin and Cherokee<br>
could be permitted to intermix within a script label horrifies me --<br>
unless the idea is to say &quot;feck it, we don&#39;t care about being<br>
responsible for enforcing any security whatsoever&quot;.</blockquote><div><br>I don&#39;t think anyone particularly wants those ones to be mixed. The question is whether the protocol forbids script mixing, or there are other means to prevent it. There are clearly legitimate uses, such as romaji in Japanese.<br>
<br>The current draft IDNA, does not forbid script mixing in the protocol. <i><b>ICANN rules forbid it, which is a very different matter</b></i> (with some exceptions, which as we&#39;ve said, are not clearly defined).<br>
<br>If you are concerned about IDNA issues, then you should stay current with the drafts:<br><br><tt><small>30 Nov 2008</small></tt>  <a href="http://tools.ietf.org/html/draft-ietf-idnabis-bidi">draft-ietf-idnabis-bidi</a>
<br>
<tt><small>09 Mar 2009</small></tt>  <a href="http://tools.ietf.org/html/draft-ietf-idnabis-defs">draft-ietf-idnabis-defs</a>
<br>
<tt><small>09 Mar 2009</small></tt>  <a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol">draft-ietf-idnabis-protocol</a>
<br>
<tt><small>09 Mar 2009</small></tt>  <a href="http://tools.ietf.org/html/draft-ietf-idnabis-rationale">draft-ietf-idnabis-rationale</a>
<br>
<tt><small>22 Dec 2008</small></tt>  <a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables">draft-ietf-idnabis-tables</a>
<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>
Was a decision to ban script-mixing within a label made? <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Or was it not<br>

made? If it was not made, I am surprised, as I thought it had been. If<br>
it was made, why the hell is it being proposed to unmake it?</blockquote><div><br>It is not banned, and has not been banned (I think) in any of the many drafts (John can say precisely).<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>
<div class="im"><br>
&gt; For many scripts it is in fact innocuous and desirable to be mixed<br>
&gt; with ASCII Latin (take Japanese and Romaji for example). In my days<br>
&gt; at Microsoft, when helping exposing IDN in IE7, we went from a<br>
&gt; fairly restrictive model to a much more open model concerning script<br>
&gt; mixing, clearly banning the problematic cases (such as Greek,<br>
&gt; Cyrillic, Latin mixing), but allowing for example most of the Asian<br>
&gt; scripts to be mixed with Latin, and<br>
&gt; obviously allowing the mixed script scenarios required for Japanese<br>
&gt; and Korean.<br>
<br>
</div>BUT WASN&#39;T THIS ALREADY DECIDED?</blockquote><div><br>See above.<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>

<div class="im"><br>
&gt; Finally the script property as exposed by Unicode cannot be used<br>
&gt; without<br>
&gt; some careful analysis to determine &#39;single&#39; script. There are values<br>
&gt; such as &#39;Common&#39; and &#39;Inherited&#39; which have to be allowed with most<br>
&gt; other script values.<br>
<br>
</div>Give examples when you make a statement like this please. Otherwise it<br>
is scare tactics.</blockquote><div><br>This is not scare tactics, and I&#39;m not the one SHOUTING. I have given examples before on the list, which it appears that you haven&#39;t noticed. The simplest are the digits 0-9. If you forbid mixing Common with Cyrillic, for example, then you can&#39;t have Cyrillic labels with digits.<br>
<br>While eliminating digits might be appropriate for TLDs, it is certainly not intended for other labels.<br><br>For an approximate list, see:<br><a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[:L:][:Mn:][:Mc:][:Nd:]-[:nfkcqc=n:]-[:defaultignorablecodepoint:]-[">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[:L:][:Mn:][:Mc:][:Nd:]-[:nfkcqc=n:]-[:defaultignorablecodepoint:]-[</a>^[:script=common:][:script=inherited:]]<br>
<br>You also couldn&#39;t use Arabic vowel marks, or accented Latin letters that aren&#39;t precomposed (needed for some African languages).<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>
<div class="im"><br>
&gt; At the same time, &#39;Common&#39; is a value that often means &#39;shared&#39; by<br>
&gt; at least two scripts, and it does not mean that all &#39;Common&#39;<br>
&gt; characters should be mixable with all scripts.<br>
<br>
</div>Ditto.<br>
<div class="im"><br>
&gt; In other words, it is way too complicated to be enshrined in a<br>
&gt; protocol<br>
&gt; where stability is a feature.<br>
<br>
</div>You have to make arguments by reference to examples that specify your<br>
concern. Even I, Unicadette that I am, don&#39;t find your argument<br>
convincing.</blockquote><div><br>I firmly agree with you as to the need for examples, but those have been supplied before, many many times, just not in that message.<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>
<div class="im"><br>
&gt; It is better done by registry policies and client application<br>
&gt; awareness. And it needs to be adjusted as new threats emerge while<br>
&gt; respecting real need for multi-script labels when no harm potential<br>
&gt; exists.<br>
<br>
</div>Even mixing Burmese and Latin is dangerous because of Latin o and<br>
Burmese wa (looks like o).</blockquote><div><br>No question. There are a huge number of characters that look like o; many of the Indic digits, for example. See above.<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>
You know, last night I sent an IM to Cary:<br>
<br>
&quot;I don&#39;t know why I remain on the IDNA list. Any time I say anything<br>
it gets ignored.&quot;<br>
<br>
Cary responded that he felt that both statements were true for<br>
everyone on the list.</blockquote><div><br>The volume does make it difficult to follow - I know I&#39;ve spent vastly more time on this than anticipated: just reading each of the new specs carefully takes a lot of time - and the main authors and chair are clearly overloaded.<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>
And these decisions will help run the internet....<br>
<br>
Dejectedly,<br>
<font color="#888888">Michael<br>
</font><div><div></div><div class="h5">_______________________________________________<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/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>