<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Consolas",serif;
        color:black;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext">This is a good taxonomy and UASG should use it consistently.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p>&nbsp;</o:p></span></p>
<pre>- identical&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; renders same in all fonts and sizes<o:p></o:p></pre>
<pre>- near identical&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; may not be perfectly identical but almost<o:p></o:p></pre>
<pre>- not reliably distinct&nbsp; may be distinct if shown side by side or in some contexts<o:p></o:p></pre>
<pre>- confusingly similar&nbsp;&nbsp;&nbsp; close enough that it can get misidentified<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>- similar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  everything else that is not clearly distinct<o:p></o:p></pre>
<p class="MsoNormal"><span style="color:windowtext"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Tl;dr Has anyone made an effort to formally assign and document these definitions to the various pairs of codepoints?<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:windowtext"><o:p>&nbsp;</o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org]
<b>On Behalf Of </b>Asmus Freytag<br>
<b>Sent:</b> Saturday, April 22, 2017 11:56 AM<br>
<b>To:</b> ua-discuss@icann.org<br>
<b>Subject:</b> Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">On 4/22/2017 9:16 AM, Andrew Sullivan wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>On Sat, Apr 22, 2017 at 01:32:08PM &#43;0000, <a href="mailto:nalini.elkins@insidethestack.com">nalini.elkins@insidethestack.com</a> wrote&gt; <o:p></o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>For example, you may wish to see the following permutations which have already been obtained.&nbsp; (And, it appears not by Apple)<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre><a href="https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.appl%C3%A9.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=7AeEjwBOAUuTZni%2BtlW2pglIHJWziZUmFXBVkj8tmu0%3D&amp;reserved=0">www.applé.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-epa.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=rzozQnV9CmdvL0GNeA86jF%2FxQd%2FPH5Nlx4P6XdMbpeI%3D&amp;reserved=0">www.xn--appl-epa.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-epa.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=rzozQnV9CmdvL0GNeA86jF%2FxQd%2FPH5Nlx4P6XdMbpeI%3D&amp;reserved=0">www.xn--appl-epa.com</a>&nbsp;&nbsp;&nbsp;&nbsp;  <o:p></o:p></pre>
<pre><a href="https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.appl%C3%AA.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=XmA9oTgfjmMMENGBpHAt%2BPiNS265Nf2To0BKQCt1YFw%3D&amp;reserved=0">www.applê.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-jpa.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=ZbRL0pJWEpCEx3mu7VAZUcY71F34EUEjbMpQitt6hm0%3D&amp;reserved=0">www.xn--appl-jpa.com</a>&nbsp;&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-jpa.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=ZbRL0pJWEpCEx3mu7VAZUcY71F34EUEjbMpQitt6hm0%3D&amp;reserved=0">www.xn--appl-jpa.com</a>&nbsp;&nbsp;&nbsp;  <o:p></o:p></pre>
<pre><a href="https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.appl%C4%97.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=ElC%2BhWkrOcc0g8ymd9cwmFN5IYYMjcHLbD0nPzBdFJs%3D&amp;reserved=0">www.applė.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-yva.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502200236&amp;sdata=H4Fexf%2BPXWpX5N8Mz3537rn%2BKEiI94At1dLO3DbyA8U%3D&amp;reserved=0">www.xn--appl-yva.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-yva.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502210244&amp;sdata=m3KBHt5D6gvVhvoz3UN0OF0JuVf7DYRnNdTkVmr7U20%3D&amp;reserved=0">www.xn--appl-yva.com</a>&nbsp;&nbsp;&nbsp;&nbsp;  <o:p></o:p></pre>
<pre><a href="https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.appl%C4%99.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502210244&amp;sdata=2RzdtTxXDhh7FgDDKcUDaFry1pKgNPBH7terxnwtVds%3D&amp;reserved=0">www.applę.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-8va.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502210244&amp;sdata=NhOdoGYZLiqqty40SpYdMJzfba2FtQSVRm0ZbBxf%2F4o%3D&amp;reserved=0">www.xn--appl-8va.com</a>&nbsp;&nbsp; <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xn--appl-8va.com&amp;data=02%7C01%7Cmarksv%40microsoft.com%7Cc811d8abe0db425bfea708d489b1306f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636284841502210244&amp;sdata=NhOdoGYZLiqqty40SpYdMJzfba2FtQSVRm0ZbBxf%2F4o%3D&amp;reserved=0">www.xn--appl-8va.com</a><o:p></o:p></pre>
</blockquote>
<pre><o:p>&nbsp;</o:p></pre>
<pre>Do you think that those qualify as &quot;homographs&quot;?&nbsp; I suppose they<o:p></o:p></pre>
<pre>might, as might àpple.com and so on, but these at least don't seem to<o:p></o:p></pre>
<pre>me to be any different than app1e.com, which we decided long ago was<o:p></o:p></pre>
<pre>Apple's problem and nobody else's. <o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
The claim that letters with diacritics are homoglyphs of the undecorated letters is<br>
rather tenuous. There are some words where diacritics are optional in some languages,<br>
and for those words, even a native reader may not notice the difference in spelling,<br>
but that is not all that different from &quot;color&quot; vs. &quot;colour&quot;.<br>
<br>
A slightly stronger case might be made that some diacritics are not reliably<br>
distinguished from each other. Cedilla and comma below come to mind. There are<br>
plenty of examples, mostly in print, that show the use of one in place of the other,<br>
even if the language ostensibly calls for a specific one and not the other. Their shapes<br>
are not so different that the substitution would always be jarring.<br>
<br>
Extending that, it's generally the diacritics below that are less readily distinguished<br>
from each other; partially that's because there's less real estate in the glyph (and the
<br>
bottom of the line may be clipped by the following line of text if the spacing is too<br>
tight).<br>
<br>
The real issue with diacritics is when multiple ones are applied to a base letter.
<br>
While they are supposed to stack neatly outward in the order that they are entered,<br>
there isn't room enough at the bottom of the glyph to show that reliably. Also,<br>
sometimes diacritics &quot;overprint&quot; instead of stacking.<br>
<br>
From a perspective of making IDNs universally acceptable, registries should be<br>
encouraged to restrict the use of dual diacritics unless central to the writing system,<br>
as it is for Vietnamese. The Unicode principle of allowing all combinations is fine<br>
for general texts (or more likely, academic texts), but misplaced for identifiers.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre> <o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>This is quite different to the case of true homoglyphs of the sort<o:p></o:p></pre>
<pre>that Asmus is talking about, where the very same glyph is normally<o:p></o:p></pre>
<pre>used in two different scripts such that nobody would be able to tell<o:p></o:p></pre>
<pre>the difference.&nbsp; One maybe could argue that &quot;аррӏе&quot; is pure homoglyphs<o:p></o:p></pre>
<pre>(0430,0440,0440,04CF, 0435), but I think it's tough to argue for it.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
&quot;арр&quot; / &quot;app&quot; or &quot;аре&quot; / &quot;ape&quot; would be true homographs (always identical), <br>
but the palochka (04CF - &quot;ӏ&quot;) is at best a near homoglyph. It renders<br>
identical in many fonts, even though it can be rather distinct in <br>
others (especially certain console fonts).<br>
<br>
<img border="0" width="188" height="67" style="width:1.9583in;height:.6979in" id="_x0000_i1025" src="cid:image001.png@01D2BCDA.B4F2F740"><br>
<br>
Since those console fonts are a minority, the Palochka should probably be treated<br>
conservatively as a homoglyph.<br>
&nbsp;<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><o:p>&nbsp;</o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>Remember, the IDNA rules are really _quite_ restrictive, and if<o:p></o:p></pre>
<pre>registries also require &quot;same script per label&quot; those restrictions<o:p></o:p></pre>
<pre>catch an _awful_ lot of corner cases (that was the outcome of the<o:p></o:p></pre>
<pre>&quot;paypal&quot; controversy some time ago).<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>If you want to argue that policy should be different, that's fine, but<o:p></o:p></pre>
<pre>it seems to me to require some PDP within ICANN.&nbsp; Note that ICANN is<o:p></o:p></pre>
<pre>probably going to propose some rules for variant handling, and<o:p></o:p></pre>
<pre>combined with the LGR stuff that is working its way through the system<o:p></o:p></pre>
<pre>we may find an awful lot of stuff is blocked.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
Actually, you can block &quot;an awful lot&quot; and yet not affect the universe of valid <br>
labels very much. <br>
<br>
A case in point is Ethiopic, which for linguistic reasons I won't go into, is best
<br>
handled by treating a number of code points internal to the script as variants of<br>
each other (making them mutually exclusive if they occur as alternates in otherwise<br>
identical labels). <br>
<br>
The linguistic reasons apply, strictly speaking, only to one of the languages (albeit<br>
the most prominent one). The concern was raised how that would interfere with<br>
the ability to register labels in other languages.<br>
<br>
For the TLD IDN project we ran an analysis over a corpus of unique words, separated<br>
by language. We found that the reduction in available labels was much less than<br>
one might have guessed from the considerable number of variants. The reductions<br>
came to a few percent, much less than the effect of the languages sharing words<br>
that happened to be spelled the same (e.g. like English/French &quot;but&quot; or Englis/German<br>
&quot;also&quot;).<br>
<br>
The main reason for this is that legitimate labels would tend to contain at least one
<br>
distinct code point, enough to prevent the label from being blocked. (Just as<br>
&quot;dapple&quot; is no longer a homograph of any Cyrillic string even if &quot;apple&quot; is.)<br>
<br>
The other reason is many strings that would otherwise be homographs do not <br>
make sense in the other context, and therefore are much less likely to be used for<br>
legitimate labels (and only used for phishing).<br>
<br>
Just like the string &quot;аррӏе&quot; (using Cyrillic code points) makes no sense to anyone<br>
using a language written in Cyrillic.<br>
<br>
For short labels, acronyms etc. might increase the set of legitimate labels beyond<br>
the word analysis we were doing, but it would be instructive to run such experiments<br>
on Latin/Cyrillic corpora assuming the widest definition of homoglyph variants;<br>
if those corpora are not limited to dictionary words, but include names, brands<br>
and acronyms, that would yield a pretty reliable estimate. <br>
<br>
I predict that the overlap will prove smaller than feared, for the same reasons<br>
that we found for Ethiopic, some high visibility exceptions notwithstanding.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><o:p>&nbsp;</o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>In any case, I think our purpose is very badly served by conflating<o:p></o:p></pre>
<pre>these two different kinds of issues.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Agreed. Our purpose is best served by making careful distinctions among these:<o:p></o:p></p>
<pre>- identical&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; renders same in all fonts and sizes<o:p></o:p></pre>
<pre>- near identical&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; may not be perfectly identical but almost<o:p></o:p></pre>
<pre>- not reliably distinct&nbsp; may be distinct if shown side by side or in some contexts<o:p></o:p></pre>
<pre>- confusingly similar&nbsp;&nbsp;&nbsp; close enough that it can get misidentified<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>- similar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  everything else that is not clearly distinct<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<p class="MsoNormal">My take is that there is a call for addressing the first two at the level of an LGR
<br>
(registry policy) and that the third requires some judgement call on whether it's
<br>
more like the first two, or more like the latter two. <br>
<br>
A./<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><o:p>&nbsp;</o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>Best regards,<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>A<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
</blockquote>
<p><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>