<div dir="ltr"><div class="gmail_default" style="font-family:'times new roman',serif">> <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">that is not the argument mark</span></div><div class="gmail_default" style="font-family:'times new roman',serif">

<br></div><div class="gmail_default" style="font-family:'times new roman',serif">I'm not sure why it isn't the argument. When I say <i>X is confusable with Y</i>, I mean "X looks like Y but is encoded differently". That appears to be exactly the same as your "<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">different encodings of what looks like the same thing</span>". </div>

<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">So I'll try translating P1 into your terms:</div>

<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif"><span style="color:rgb(0,0,0);font-size:11px">P1: Any characters that are visually confusable with others should be excluded from domain names.</span><br>

</div><div class="gmail_default" style="font-family:'times new roman',serif"><span style="color:rgb(0,0,0);font-size:11px">=></span></div><div class="gmail_default" style="font-family:'times new roman',serif">

<span style="color:rgb(0,0,0);font-size:11px">P1: Any characters that are have different encoding but look the same as others should be excluded from domain names.</span><span style="color:rgb(0,0,0);font-size:11px"><br>
</span></div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">

<div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">

<a href="https://google.com/+MarkDavis" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">

<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div>
<br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 6:22 AM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">that is not the argument mark - it has to do with different encodings of what looks like the same thing - that can be exploited by phishing, for example.<span class="HOEnZb"><font color="#888888"><div><br>
</div>
<div>v</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 9:20 AM, Mark Davis ☕️ <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_default" style="font-family:'times new roman',serif">The problem with excluding this one particular character is that it introduces a discrepancy with no real value. It's a bit like addressing global warming by requiring that Harley Davidsons with licence plate numbers divisible by 3 cannot use the US interstate. It might make some people feel like they are doing something good, but just complicates the rules with no measurable benefit.</div>




<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">The principle that is being espoused is something like: </div>




<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">P1: Any characters that are visually confusable with others should be excluded from domain names.<br>




</div><div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">But why apply that principle to this (rather rare) character, that is only used in a particular language, when it is not applied to thousands of other characters, and characters that are vastly more commonly used? And if P1 is not the principle that is being applied, what is?</div>




<div class="gmail_default" style="font-family:'times new roman',serif"><br></div></div><div class="gmail_extra"><div><br clear="all"><div><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">




<div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">




<a href="https://google.com/+MarkDavis" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">




<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div>
<br><br></div><div><div><div class="gmail_quote">On Wed, Aug 6, 2014 at 5:02 AM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">Mark,<div><br></div><div>I think it is important to distinguish the use of a character for purposes other than domain names and for use in domain names. The long preface in your email makes that case that the character is useful and legitimate in the language but I think it has long been understood that domain names have properties and requirements for unambiguous comparison that might lead to the conclusion that, despite the character's undeniable utility in written language, it may still not be appropriate for use in domain names. </div>





<div><br></div><div>In consequence of that line of reasoning, I would separate the legitimate presence of the character in UNICODE from its use in domain names. </div><div><br></div><div>The next question, of course, is whether there is any harm to users that can be anticipated by the use of the character in domain names. I think it is clear that whatever conclusion is reached, it should apply to all levels of domain name and therefore to all labels. Adopting a rule concerning a character that is applied only at TLD or SLD level but cannot be enforced at lower levels of a DNS hierarchy seems like a mistake, so if there is a problem with a character, that problem should be solved for all use in labels.</div>





<div><br></div><div>I want to emphasize that, so far in this text, I have not taken a position regarding the use of U+08A1 in domain names. I am only discussing the process of deciding whether a character should be rendered invalid for use in domain name labels. The argument that the character is useful for properly formed written language is not necessarily an argument for its permitted use in domain names, if harms are identified in the latter usage that are considered unacceptable.</div>





<div><br></div><div>It is also clear from past experience that reasonable people can differ in their assessment of the degree of risk or harm that a particular character poses. So, now we get to the central question whether U+08A1 produces sufficient risk to be banned from use in domain names. </div>





<div><br></div><div>In Klensin's draft RFC, the argument is made that the previous way in which BEH WITH HAMZA ABOVE was accommodated, including for use in domain names, was a sequence U+<span style="color:rgb(0,0,0);font-size:1em">0628 followed by U+0654. The incorporation of a new, combined character U+08A1 creates ambiguity because there would be two ways for this character to be used in a domain name, but the two do not compare equal. For users, this creates the risk that two labels could be registered that would look the same but presumably take one to distinct destinations in the event that two different registrations of labels containing instances of these characters (pre-composed U+08A1 and the U+0628/U+0654 sequence) were permitted. Making U+08A1 PVALID while also allowing the earlier composed form creates exactly this ambiguity. </span></div>





<div><span style="color:rgb(0,0,0);font-size:1em"><br></span></div><div><span style="color:rgb(0,0,0);font-size:1em">This is not a trivial problem. There are similar problems even in the purely Latin character cases where numbers and letters can look the same, depending on fonts, but be distinct for purposes of label comparisons. The fact that such problematic forms exist should not be an argument for introducing more of them. </span></div>





<div><span style="color:rgb(0,0,0);font-size:1em"><br></span></div><div><span style="color:rgb(0,0,0);font-size:1em">I think this discussion boils down to a principle of not introducing additional ambiguity where there had been none before. It is also fair to say that this is not a question of excluding the character itself from UNICODE for which ample argument has been made for its inclusion, but a question of allowing or disallowing its use in domain name labels. </span></div>




<span><font color="#888888">
<div><span style="color:rgb(0,0,0);font-size:1em"><br></span></div><div><span style="color:rgb(0,0,0);font-size:1em">vint</span></div><div><span style="color:rgb(0,0,0);font-size:1em"><br></span></div></font></span></div>




<div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>On Tue, Aug 5, 2014 at 7:07 PM, Mark Davis ☕️ <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span> wrote:<br></div>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div><div dir="ltr"><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div>







</div></div></div>
<div class="gmail_default" style="font-family:'times new roman',serif;display:inline">​I hadn't heard back from John, but I'm guessing that the right place to discuss this is here​, based on Marc's email.</div>







<div><font face="times new roman, serif"><br></font><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Mark Davis ☕️</b> <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span><br>







Date: Wed, Jul 30, 2014 at 7:38 AM<br>Subject: Re: Unicode 7.0.0, (combining) Hamza Above, and normalization for comparison<br>To: John C Klensin <<a href="mailto:john%2Bw3c@jck.com" target="_blank">john+w3c@jck.com</a>>, Patrik Fältström <<a href="mailto:paf@frobbit.se" target="_blank">paf@frobbit.se</a>><br>







Cc: <a href="mailto:member-i18n-core@w3.org" target="_blank">member-i18n-core@w3.org</a>, Asmus Freytag <<a href="mailto:asmusf@ix.netcom.com" target="_blank">asmusf@ix.netcom.com</a>><br><br><br><div dir="ltr"><div style="font-family:'times new roman',serif">







​On what email address is this being discussed?  I'd like to convey to that list some comments from an internal discussion​ about <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">draft-</span><span style="font-family:arial,sans-serif;font-size:11px">klensin</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">-idna-5892upd-unicode70-00.txt</span>. </div>








<div style="font-family:'times new roman',serif"><br></div><div style="font-family:'times new roman',serif">(These are not my wording, but I agree with them. I edited slightly for flow. I will add that from a confusability standpoint, the proposed draft accomplishes nothing, since there are thousands of cases of confusable characters; restricting just this one character has no useful effect; like removing a quart of water from a lake.)</div>









<div style="font-family:'times new roman',serif"><br></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">For U+08A1, this certainly is a *letter* of Fula (Fulfulde, Pula, ...),</span></div>








<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">a large language spoken across swaths of</span></div><div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">West Africa. Fula is mostly written with the Latin script,</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">but Islamists also write it in Ajami (Arabic extensions for African</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">languages), particularly in Guinea.</span></font></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">See:</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><a href="http://en.wikipedia.org/wiki/Fula_orthographies" style="font-family:arial,sans-serif;font-size:11px" target="_blank">http://en.wikipedia.org/wiki/Fula_orthographies</a><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">The *letter* in question is the one used to write the phoneme /ɓ/,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">the bilabial implosive. See:</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<a href="http://en.wikipedia.org/wiki/%C6%81" style="font-family:arial,sans-serif;font-size:11px" target="_blank">http://en.wikipedia.org/wiki/%C6%81</a><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">for the African alphabet convention for the Latin writing of this letter.</span></div>








<div><br></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">For the Arabic Ajami alphabets for Fula, the form has been missing.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">For whatever reason, in at least one Fulfulde Ajami orthography,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">this implosive was (reasonably) represented by using a Hamza</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">diacritic on the beh letter. Following the way such *diacritic* (ijam)</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">letter derivations are encoded in the Unicode Standard, a separate,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">non-decomposed entry was required. Note that this use of Hamza</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">is *different* from the Arabic (language) use of a combining Hamza</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">to indicate a glottal stop, often in combination with a letter that</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">is actually pronounced as a vowel.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><div>
<br></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">As to *why* it was encoded as a single, undecomposed letter,</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">that is explained at length in the proposal document, as well</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">as in the section on Hamza in the Unicode Standard, which you</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">have referred to in the Internet Draft you mention.</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br>








</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">The newly encoded character U+08A1 for Unicode 7.0 has</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">*already* been added to the relevant table "Arabic Letters</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">With Hamza Above" in the draft core specification for</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">Unicode 7.0, where, like the long-encoded U+0681</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">and U+076C, it is noted as having no decomposition.</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">(The core specification will be posted around October -- it</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">is still undergoing its final editing for all the 7.0 additions.)</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br>








</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">U+08A1 does not have a canonical decomposition in Unicode 7.0</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">(nor, of course, will it *ever* have a canonical decomposition,</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">because of normalization stability). This is exactly the same treatment</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">that U+0681 and U+076C got, and for exactly the same reasons.</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">(And, as you know, of course, those characters date back to</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">Unicode 4.1 for U+076C and even earlier, Unicode 1.1 for U+0681.)</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">Note that it is incorrect to assert that U+08A1 ARABIC LETTER BEH</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">WITH HAMZA ABOVE "should" be normalized to U+0628 ARABIC LETTER</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">BEH + U+0654 ARABIC HAMZA ABOVE. Those are distinct sequences,</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">and they are never going to compare equal in their NFC normalizations.</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">I am concerned that the Internet Draft here is heading in</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">exactly the wrong direction. If it ends up changing RFC 5892</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">to override the derivation for U+08A1 and force it to INVALID,</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">all I can see that accomplishing is to guarantee forever that</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">correctly spelled Ajami Fulfulde cannot be used in domain</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">names, and that instead people would end up having to use</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">misspellings to represent their implosive b in a domain names.</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">With all due respect to the Arabic script experts that have been</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">consulted, I rather doubt that they are experts on Ajami orthographies</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">in West Africa, or are in touch with the people who would be</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">supporting those languages and implementing keyboarding</span></font></div>








<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">and such for West Africa.</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br>
</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">Also, I don't see any way you can justify the abrupt (and permanent)</span></font></div>
<div><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">discontinuity that this would put in place between the treatment</span></font></div><div>
<font color="#000000" face="arial, sans-serif"><span style="font-size:11px">of U+08A1 for Fulfulde and U+076C for Ormuri or U+0681 for Pashto.</span></font></div></div><div style="font-family:'times new roman',serif">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">If you are looking for a more analogous precedent </span><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">I suggest, for example:</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">U+2C65 LATIN SMALL LETTER A WITH STROKE</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">That was added in Unicode 5.0, and nobody has ever had any problem</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">with it being PVALID in IDNA. It only has limited use in a minor orthography,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">but what is the harm?</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">Now, if you examine U+2C65, you could well claim that it *should*</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">be decomposed to "a" plus the combining stroke overlay, U+0338.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">And both of those have been encoded for a long, long time in</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">the standard, so in principle, somebody *could* have been representing</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">their data for a letter a with stroke before Unicode 5.0 using the sequence with the stroke</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">overlay. It might even look o.k. in text, depending on the font support</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">for the combina̸tion. But the Unicode Standard has rules now for the</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">encoding of certain combinations of base letters and diacritic modifiers</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">that overlay or modify the base character form. So U+2C65 was</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">separately encoded. And there is no normalization of the sequence</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">involved. That stroked letter use is, in text, distinct from somebody, say,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">using a bunch of overlay strokes as a strikethrough convention for</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">some reason: a̸a̸a̸a̸a̸a̸</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">Consider the Hamza diacritic as falling in this same class of edge cases,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">if you will.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">And in this case, I don't think it will be doing anybody any favors to</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">update RFC 5892 to make U+08A1 DISALLOWED in IDNA. It doesn't</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">"fix" normalization for it. All it accomplishes is to force any Fulfulde</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">user of Ajami orthography to misspell their text in order to use a /ɓ/</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">in a domain name. It would just create an unexplained (and unfixable)</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">discontinuity between what the domain registrations would accept</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">and what the Fulfulde input and spelling tools would support. Or I</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">guess it would just force people to give up the Arabic spellings and</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">go back to the more widely supported Latin alphabets for Fula to</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">get their domain names.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">What would be accomplished by</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">forcing another point incompatibility that just ends up getting</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">carried around forever?</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">









</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="'times new roman', serif"><div style="margin:0px;background-color:transparent">
<div></div></div><div style="margin:0px;background-color:transparent"><div style="font-family:'times new roman',serif">​====</div><div style="font-family:'times new roman',serif">
​</div></div></font></div></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">There are four levels at which confusables, including homoglyphs<div style="font-family:'times new roman',serif;display:inline">








​,​</div> can be addressed for domain names</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"></div><div class="gmail_extra">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">1. Encoding</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">2. Protocol (IDNA)</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">3. Label Generation Ruleset</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">4. String Review</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><div style="font-family:'times new roman',serif;display:inline">








​A</div> more natural leve</span><font color="#000000" face="arial, sans-serif"><span style="font-size:11px">l ​[for ​addressing ​confusables​] ​​would</span></font><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"> be the Label Generation Ruleset level. For an LGR, there are three ways to deal with homoglyphs, one of which is not available on the protocol level. The first two of these are to rule out a code point (by not including it in the LGR's repertoire), or to rule out a code point or sequence conditionally. Unlike using these methods on the Protocol level, doing so on the LGR level means that it is possible to be more restrictive, say, for the root of the DNS than for domains several levels down the tree. The downside of using the LGR is, of course, that it is specific to the given zone on the internet.</span></div>








<div class="gmail_extra"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">The upside is that an LGR has additional mechanisms, such as defining a "blocked" variant. That creates an "either/or" situation, where both are permitted, but not at the same time in the same position of an otherwise identical label. This is a very nice solution for a number of confusables/homoglyphs that are systemic (not dependent on accidents of rendering or "arms length" similarity).</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">Unlike the final level, String Review, an LGR has the advantage of being applied mechanically without any case-by-case review, which is why it's appropriate for cases like the one that gave rise to this discussion.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">








<br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px">In principle, both the Label Generation Ruleset or the String Review are created/carried out by people/entities that have access to the necessary and specific linguistic and script expertise, unlike IDNA which seems to be created largely by protocol experts.</span></div>








<div class="gmail_extra"><br></div><div class="gmail_extra"><font color="#000000" face="arial, sans-serif"><span style="font-size:11px"><br></span></font><div class="gmail_quote">On Tue, Jul 22, 2014 at 12:22 AM, John C Klensin <span dir="ltr"><<a href="mailto:john+w3c@jck.com" target="_blank">john+w3c@jck.com</a>></span> wrote:<br>








<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi.   I was asked to forward the announcement of this Internet<br>
Draft to this group once it was posted.  See attached.<br>
<br>
For information -- comments welcome, but the core issue may be<br>
rather specific to concerns that surround IDNs and IDNA.  Or not.<br>
<br>
Or course, if I/we are still completely confused, corrections<br>
and explanations would be welcome.<br>
<span><font color="#888888"><br>
    john<br>
</font></span><br><br>---------- Forwarded message ----------<br>From: <a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a><br>To: <a href="mailto:i-d-announce@ietf.org" target="_blank">i-d-announce@ietf.org</a><br>








Cc: <br>
Date: Mon, 21 Jul 2014 04:03:58 -0700<br>Subject: I-D Action: draft-klensin-idna-5892upd-unicode70-00.txt<br><br>
A New Internet-Draft is available from the on-line Internet-Drafts directories.<br>
<br>
<br>
        Title           : IDNA Update for Unicode 7.0.0<br>
        Authors         : John C Klensin<br>
                          Patrik Faltstrom<br>
        Filename        : draft-klensin-idna-5892upd-unicode70-00.txt<br>
        Pages           : 10<br>
        Date            : 2014-07-21<br>
<br>
Abstract:<br>
   The current version of the IDNA specifications anticipated that each<br>
   new version of Unicode would be reviewed to verify that no changes<br>
   had been introduced that required adjustments to the set of rules<br>
   and, in particular, whether new exceptions or backward compatibility<br>
   adjustments were needed.  That review was conducted for Unicode 7.0.0<br>
   and identified a problematic new code point.  This specification<br>
   updates RFC 5982 to disallow that code point and provides information<br>
   about the reasons why that exclusion is appropriate.  It also applies<br>
   an editorial clarification that was the subject of an earlier<br>
   erratum.<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href="https://datatracker.ietf.org/doc/draft-klensin-idna-5892upd-unicode70/" target="_blank">https://datatracker.ietf.org/doc/draft-klensin-idna-5892upd-unicode70/</a><br>
<br>
There's also a htmlized version available at:<br>
<a href="http://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-00" target="_blank">http://tools.ietf.org/html/draft-klensin-idna-5892upd-unicode70-00</a><br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submission<br>
until the htmlized version and diff are available at <a href="http://tools.ietf.org" target="_blank">tools.ietf.org</a>.<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href="ftp://ftp.ietf.org/internet-drafts/" target="_blank">ftp://ftp.ietf.org/internet-drafts/</a><br>
<br>
_______________________________________________<br>
I-D-Announce mailing list<br>
<a href="mailto:I-D-Announce@ietf.org" target="_blank">I-D-Announce@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft" target="_blank">https://www.ietf.org/mailman/listinfo/i-d-announce<br>
Internet-Draft</a> directories: <a href="http://www.ietf.org/shadow.html" target="_blank">http://www.ietf.org/shadow.html</a><br>
or <a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt" target="_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a><br>
<br></blockquote></div><br></div></div>
</div><br></div></div>
<br></div></div><div>_______________________________________________<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></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>