<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Jim.
<div class="">Just a couple of comments for clarification.</div>
<div class="">You say:</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">I see this point. On the other hand, aren't there already differences in what second-level domain names may be registered, at least for country-code top-level domains? For instance, won't the .jp top-level domain forbid names in Thai script, and
the .ht top-level domain forbid names in Japanese? But I can see confusion if .com permits registering a name which .biz forbids, and so on.</p>
</div>
</blockquote>
</div>
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">You are right. However, those are cases that are well-defined, and do not require a decision to be made on a case by case. What may happen with the “confusing similar” case is that not everybody agrees on what is similar and what is not. On the
other hand, it is clear what is a text in Thai or Japanese script, so the outcome is predictable and not depending by human judgement.</p>
</div>
</div>
<div class="">And further below:</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">It wouldn't be me or UASG advocates who open that front. It would be the fraudsters, and the users who perceive confusable domain names as being a threat. </p>
</div>
</blockquote>
</div>
<div class="">I fully agree with you. I hope that what you indicate as reason 3. (which is IMHO the most powerful argument) will be accepted as a sufficient argument. Let me add that, although I admit that the problem becomes bigger with IDN, we already have
it with ASCII labels - for instance confusing “O" and “0” - where we have no solution.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Roberto</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 23.02.2018, at 01:35, Jim DeLaHunt <<a href="mailto:jfrom.uasg@jdlh.com" class="">jfrom.uasg@jdlh.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">Roberto:</p>
<p class="">Thank you for this reply. You have experience and a perspective which I lack. I've never tried to run a domain name registry or act as registrar. This discussion is an education for me.<br class="">
</p>
<p class="">> it is not fair to leave it to individual registries to take their own choices on what is “confusingly similar" and what is not, with the result that some SLD could be registered in some TLD but not in others.…</p>
<p class="">I see this point. On the other hand, aren't there already differences in what second-level domain names may be registered, at least for country-code top-level domains? For instance, won't the .jp top-level domain forbid names in Thai script, and
the .ht top-level domain forbid names in Japanese? But I can see confusion if .com permits registering a name which .biz forbids, and so on.</p>
<p class="">> Also, according to the current scheme of the market, the interface with the registrant is the registrar, not the registry. The deletion of a registration of - or the denial to register - a domain name would create substantial contractual litigation
unless the RRA (Registry-Registrar Agreement) is changed adding specific clauses.…<br class="">
> ICANN has been violently reluctant to establish some standards of this type for fear of appearing even more as a regulator….</p>
<p class="">A difficult situation indeed!</p>
<p class="">> We have already had long, tiresome, time wasting discussions about the supposed responsibility of registries about detecting domain names “confusingly similar” to brands or marks in order to protect intellectual property, please do not open another
front that has the same technical and contractual problems.</p>
<p class="">It wouldn't be me or UASG advocates who open that front. It would be the fraudsters, and the users who perceive confusable domain names as being a threat.
<br class="">
</p>
<p class="">The fraudsters will attack any weak point they can find to commit their fraud. If the RRA, or the historical stance of ICANN, or exhaustion of people who have survived other fights about domain names, lead to an inability to combat the fraudsters,
then the fraudsters will take advantage of that. And the users will react based on their perception of threats, which may differ from the reality. That reaction may make Universal Acceptance harder to promote, whether we like it or not.</p>
<p class="">In making the case for Universal Acceptance, I think we need to come up with a credible argument for how to balance these competing forces.<br class="">
—Jim DeLaHunt<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 2018-02-22 05:15, Roberto Gaetano wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:09853392-2D66-4188-BCD1-5977DA7C1C17@hotmail.com" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
Jim,
<div class="">I share your overall rebuttal and am in favour of regular IDN labels, but have different opinions on the three items you mention.</div>
<div class="">We fully agree on 3., adding also that if we want to have a standard way to present urls it can only be showing what the user expects to see not the translation via an algorithm that will generally not be understood. The only advantage of having
punycode would be to detect potential scams but at the price of making the result unreadable.</div>
<div class="">About 2., although the observation is correct, I fail to see its value as an argument about the choice of label type - but that may well be my lack of understanding rather than the value of the argument itself.</div>
<div class="">However, I am in complete disagreement with 1. As a disclosure, I have to state that I am chairing the Board of Public Interest Registry, so it is clear that, while I am supposed to have some experience about the registry business, I have also
a vested interest in the matter.</div>
<div class="">My point is that, while in theory the registries can exert control on the domain names registrations, in practice we have a few quite substantial problems, both technical and contractual. For instance, I don’t see the possibility of developing
an algorithm to detect all the possible cases while it is not fair to leave it to individual registries to take their own choices on what is “confusingly similar" and what is not, with the result that some SLD could be registered in some TLD but not in others.
Also, according to the current scheme of the market, the interface with the registrant is the registrar, not the registry. The deletion of a registration of - or the denial to register - a domain name would create substantial contractual litigation unless
the RRA (Registry-Registrar Agreement) is changed adding specific clauses.</div>
<div class="">Talking by experience, ICANN has been violently reluctant to establish some standards of this type for fear of appearing even more as a regulator - or maybe also for other reasons - and the ball cannot be punted to the registries with the risk
of having different behaviour and therefore confusion in the market.</div>
<div class="">We have already had long, tiresome, time wasting discussions about the supposed responsibility of registries about detecting domain names “confusingly similar” to brands or marks in order to protect intellectual property, please do not open another
front that has the same technical and contractual problems. </div>
<div class="">Cheers,</div>
<div class="">Roberto<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 20.02.2018, at 09:54, Jim DeLaHunt <<a href="mailto:jfrom.uasg@jdlh.com" class="" moz-do-not-send="true">jfrom.uasg@jdlh.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">Multiple people have made the argument that having a browser show A-labels ("punycode") instead of U-labels ("regular IDN") is desirable as a way of fighting phishing.</p>
<p class="">My rebuttal has three parts:</p>
<ol class="">
<li class="">The underlying problem is that the registry (here, .com) permitted registration of a domain name which was confusable with another one. The right place to fight this kind of phishing with confusable characters is at the domain registry level.
</li><li class="">Even if you could magically prevent all confusable 2nd-level domain name registrations, phishing would still be a problem. Fraudsters have many tools, confusable 2nd-level names is only one of them. There are also confusable names at the 4th or
5th levels (e.g. <a href="http://microsoft.com.innocuous.deceptive.com/" class="" moz-do-not-send="true">
microsoft.com.innocuous.deceptive.com</a>), and misleading links in message bodies, and so on.<br class="">
</li><li class="">The people for whom A-labels instead of U-labels are a privileged set of latin-script reading Internet users. The second billion internet users will predominantly be people who read a different script than latin. U-labels are a requirement for
them to have legible domain names for legitimate sites. A-labels mean they don't get domain names which they can read. And they deserve to be able to read their domain names and email addresses.<br class="">
</li></ol>
<p class="">This is an excellent audience for me to test my rebuttal. Is it solid? Can I improve it? </p>
<p class="">Cheers,<br class="">
—Jim DeLaHunt, Vancouver, Canada<br class="">
</p>
<div class="moz-cite-prefix">On 2018-02-19 23:36, Ronald Geens wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:2441912C-9F34-41CD-9316-F69284513CD6@dnsbelgium.be" class="">
All,
<div class=""><br class="">
</div>
<div class=""> I am aware of the good work going on in the UASG to get IDN at all levels natively supported in web-adresses and email and I fully support that. </div>
<div class=""><br class="">
</div>
<div class="">On the other hand there is darker side of the web that people want to be protected from. </div>
<div class="">I just read this blog about some people that may actually find it better to see puny-code in stead of regular IDN in order to detect spam and phishing.</div>
<div class=""><a href="https://ma.ttias.be/show-idn-punycode-firefox-avoid-phishing-urls/" class="" moz-do-not-send="true">https://ma.ttias.be/show-idn-punycode-firefox-avoid-phishing-urls/</a> which is an opposite view of what UASG is trying to achieve.</div>
<div class=""><br class="">
</div>
<div class=""> Does/Will the UASG have a standpoint in this matter ? Is this in scope of UASG or will we rely on the anti-virus industry or even registrars/registries to protect the world from abuses like this ?</div>
<div class=""><br class="">
</div>
<div class="">Best regards,</div>
<div class=""><br class="">
</div>
<div class="">Ron Geens</div>
<div class="">DNS Belgium</div>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
--Jim DeLaHunt, <a class="moz-txt-link-abbreviated" href="mailto:jdlh@jdlh.com" moz-do-not-send="true">jdlh@jdlh.com</a> <a class="moz-txt-link-freetext" href="http://blog.jdlh.com/" moz-do-not-send="true">http://blog.jdlh.com/</a> (<a class="moz-txt-link-freetext" href="http://jdlh.com/" moz-do-not-send="true">http://jdlh.com/</a>)
multilingual websites consultant
355-1027 Davie St, Vancouver BC V6E 4L2, Canada
Canada mobile +1-604-376-8953
</pre>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
--Jim DeLaHunt, <a class="moz-txt-link-abbreviated" href="mailto:jdlh@jdlh.com">jdlh@jdlh.com</a> <a class="moz-txt-link-freetext" href="http://blog.jdlh.com/">http://blog.jdlh.com/</a> (<a class="moz-txt-link-freetext" href="http://jdlh.com/">http://jdlh.com/</a>)
multilingual websites consultant
355-1027 Davie St, Vancouver BC V6E 4L2, Canada
Canada mobile +1-604-376-8953
</pre>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>