<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)">
<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:"Shonar Bangla";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
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;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@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 lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">As long as we’re being very open about the identifiers, I think that DNS may have been intended to be unique identifiers, but they have evolved into human readable
 (for the most part) identifiers.  If they were “just” unique, a bunch if #s would’ve sufficed.  Clearly now they are not just unique identifiers, but also cater to linguistic behavior.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think that the important part of the name resolution isn’t whether or not certain characters are “allowed”, but rather that they resolve to the same thing (eg:
 they’re identifiers).  I don’t think that it’s important that DNS support all possible combinations, but that where names are resolved that they are consistent.  Currently 5 names can resolve to the same IP, and I don’t see a problem with that.  So I think
 that it should be totally possible for the “confusable” characters to merely resolve to the same thing.  Eg: be bundled.  Sure, then people can’t register some names that use similar letters (or variations), but then it isn’t confusing.  Also you have a round-tripping
 problem because if 5 names resolve to the same thing, which do you display?  <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Shawn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Idna-update [mailto:idna-update-bounces@alvestrand.no]
<b>On Behalf Of </b>Vint Cerf<br>
<b>Sent:</b> Saturday, January 24, 2015 6:45 AM<br>
<b>To:</b> Martin J. Dürst<br>
<b>Cc:</b> John C Klensin; Asmus Freytag; idna-update@alvestrand.no; The IESG<br>
<b>Subject:</b> Re: [Json] Json and U+08A1 and related cases<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I have been following this discussion with some interest and have come away with a thought that some of you may wish to refine or perhaps debate. Basically, I see the UNICODE effort as only partly aligned to the needs of the Internet's
 Domain name System and the effort to use the UNICODE character parameters/descriptors/properties does not always line up with the desirable properties of the use of characters in the DNS. It seems to me useful to recall that domain names are identifiers that
 are not expected or even intended to follow purely linguistic constraints. They are used to create what are intended to be unique identifiers. Characters that have a high probability of looking the same but are encoded differently work against that goal. Of
 course I am fully aware of the confusability of the lower case letter "L" and the digit "ONE" (and "OH" and "ZERO") that is sometimes used as an example of the inconsistent toleration of confusion in the ASCII labels but I consider this to be an argument of
 the form "you allowed a case of confusion therefore you should tolerate all confusion". <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I do wonder whether it is worth considering an attempt to create a new set of properties of UNICODED characters that are of specific use to the DNS. The IDNA 2008 work tried to use properties of characters developed for purposes other than
 the DNS and the fit is not always perfect. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">vint<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Jan 23, 2015 at 4:14 AM, "Martin J. Dürst" <<a href="mailto:duerst@it.aoyama.ac.jp" target="_blank">duerst@it.aoyama.ac.jp</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">Hello Asmus,<br>
<br>
On 2015/01/22 11:58, Asmus Freytag wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I would go further, and claim that the notion that "*all homographs are<br>
the**<br>
**same abstract character*" is *misplaced, if not incorrect*.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
That's fine. Nobody would claim that 8 (U+0038) and <span style="font-family:"Shonar Bangla",sans-serif">
৪</span> (Bengali 4, U+09EA) are the same abstract character. (How 'homographic' they look will depend on what fonts your mail user agent uses :-)<br>
<br>
<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">U+08A1 is not the only character that has a non-decomposable homograph, and<br>
because the encoding of it wasn't an accident, but follows a principle<br>
applied<br>
by the Unicode Technical Committee, it won't, and can't be the last<br>
instance of<br>
a non-decomposable homograph.<br>
<br>
The "failure of U+08A1 to have a (non-identity) decomposition", while it<br>
perhaps<br>
complicates the design of a system of robust mnemonic identifiers (such<br>
as IDNs)<br>
it appears not be be due to a "breakdown" of the encoding process and<br>
also does<br>
not constitute a break of any encoding stability promises  by the Unicode<br>
Consortium.<br>
<br>
Rather, it represents reasoned, and principled judgment of what is or<br>
isn't the<br>
"same abstract character". That judgment has to be made somewhere in the<br>
process, and the bodies responsible for character encoding get to make the<br>
determination.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
While I can agree with this characterization, many judgements on character encoding are by their very nature borderline, and U+08A1 definitely in many aspects is borderline. What I hope is that the Unicode Technical Committee, when making future, similar decisions,
 hopefully puts the borderline a bit more in support of applications such as identifiers, and a bit less in favor of splitting. Also, that it realize that when principles lead to more and more homograph encodings, it may very well pay off to reexamine some
 of these principles before going down a slippery slope.<br>
<br>
Regards,   Martin.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>