<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 7:43 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The point here is that there are two ways to encode the same character and none of the normalization mechanisms transforms the representation into a single, canonical encoding. The result is ambiguity for comparing one label to another in the domain names, leading to the potential for phishing. The principle is to try to avoid that outcome. </blockquote>
</div><br><div class="gmail_default" style="font-family:'times new roman',serif">When someone says "<span style="font-family:arial">two ways to encode the same <b>character</b></span>", then they have make it clear as to which of the <i>very</i> many senses of "character" that is meant. One quite common sense is "has the same visual appearance" (or confusingly similar). Another is "canonically equivalent" according to Unicode. There are definitely differences between these: there are code point sequences that have the same appearance that are not canonically equivalent, such as Greek omicron and Latin o.</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 Unicode consortium defines the following to <b>not</b> be canonically equivalent, even though they may look the same, which is why the former was encoded.</div>
<div class="gmail_default" style><ol style="font-family:'times new roman',serif"><li>U+08A1 ARABIC LETTER BEH <font face="times new roman, serif">WITH HAMZA ABOVE</font><br></li><li><font face="times new roman, serif">U+0628 ARABIC LETTER </font>BEH + U+0654 ARABIC HAMZA ABOVE</li>
</ol><div style><font face="times new roman, serif">Thus because these sequences are not canonically equivalent, the consortium ended up encoding #1 for use in Fula. This was intentional, according to the character encoding model for Arabic, </font><i style="font-family:'times new roman',serif">not an oversight</i><font face="times new roman, serif">.</font></div>
<div style="font-family:'times new roman',serif"><br></div></div><div class="gmail_default" style="font-family:'times new roman',serif">Similarly, the consortium defines the following to <b>not</b> be canonically equivalent, even though they may look the same.</div>
<div class="gmail_default" style><div class="gmail_default" style><ol style><li style="font-family:'times new roman',serif">U+00D8 (Ø) LATIN CAPITAL LETTER O WITH STROKE<br></li><li style><span style="font-family:'times new roman',serif">U+004F (</span><span style="font-family:'times new roman',serif">O) </span><span style="font-family:'times new roman',serif">LATIN CAPITAL LETTER O + </span><font face="times new roman, serif">U+0338 ( ̸ ) COMBINING LONG SOLIDUS OVERLAY</font></li>
</ol></div></div><div class="gmail_default" style><div><span style="font-family:'times new roman',serif">Thus if (sa</span><font face="times new roman, serif">y) Danish had been a relatively obscure language, and Ø had not been encoded, it would have been ok to encode #1 for Danish.</font></div>
<div><font face="times new roman, serif"><br></font></div><div><font face="times new roman, serif">Compare that with the following, which both look the same, <b><i>and</i></b> which are defined to be canonically equivalent.</font></div>
<div><ol><li><span style="font-family:'times new roman',serif">U+00D6 ( Ö ) LATIN CAPITAL LETTER O WITH DIAERESIS</span><br></li><li><span style="font-family:'times new roman',serif">U+004F ( O ) LATIN CAPITAL LETTER O + U+0308 ( ̈ ) COMBINING DIAERESIS</span><br>
</li></ol></div><div><div class="gmail_default"><font face="times new roman, serif">The consortium supplied specification and code for determining canonical equivalence, and for confusability. The latter is being constantly refined as more information is determined, so it not appropriate for use at a protocol level, rather for higher level tools and processes.</font></div>
<div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif">If one means a third sense of "character" (neither "glyph" or "canonically equivalent"), then that needs to be made clear what is meant, and what mechanism can be used to determining when two sequences do and don't represent the same "character" in that sense.</font></div>
</div></div><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">
<br></div><div style="margin:0px;background-color:transparent"><a href="https://google.com/+MarkDavis" target="_blank">Mark</a></div><div style="margin:0px;background-color:transparent">
<i><br></i></div><div style="margin:0px;background-color:transparent"><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>
</div></div>