<div dir="ltr">How would registry to registry variation in IDN implementation reflect on a global user experience ?  if there are major differences across registries then users will be confused and affects the whole progress of IDN.<div><br></div><div>I think the guidelines should create uniformity across registries and a single clear linguistic user experience.</div><div><div><br></div><div><br></div></div><img src="http://t.sidekickopen55.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4LQ_-W5v0H7d5v_Sg6N3MPbH6QFLCHW2Ns_Yx1k1H6H0?si=6589018912063488&amp;pi=e179822d-03dd-4d3d-f5fc-da1d4ccb2bd2" style="display:none!important" height="1" width="1"></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 5, 2016 at 6:38 AM, Edmon Chung <span dir="ltr">&lt;<a href="mailto:edmon@registry.asia" target="_blank">edmon@registry.asia</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Everyone,<br>
<br>
It has come to my attention in the recent public comments regarding registry agreement amendment that Google has expressed that it seems they do not wish for these IDN Guidelines to be hard requirements for gTLDs:<br>
<br>
==============================<wbr>========<br>
Specification 6, Section 1.4 (IDNs): [Google Registry] expressed concern that the proposed language would permanently prevent registries from being able to predictably negotiate potential changes to the provision of IDNs that conflicted with the IDN Guidelines, as the IDN Guidelines would continue to control even if these services had been reviewed, approved, and reflected in the respective Registry Operator’s Exhibit A. Thus, [Google Registry] recommended that the proposed text be revised to reflect that if there is an approved RSEP allowing the Registry to deviate from the IDN Guidelines, the IDN-related provisions of Exhibit A would control.<br>
==============================<wbr>========<br>
<br>
Given our discussion so far, I think we intend for these IDN Guidelines to be overarching requirements that should never be conflicted with.<br>
<br>
If that is the idea for these IDN Guidelines, then we should alert ICANN not to allow such &quot;exceptions&quot;.  If there exist a case that such an &quot;exception&quot; is needed, the proper approach maybe to update these IDN Guidelines...<br>
<br>
Wonder what others think...<br>
<br>
Edmon<br>
<br>
<br>
______________________________<wbr>_________________<br>
Idngwg mailing list<br>
<a href="mailto:Idngwg@icann.org">Idngwg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/idngwg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/idngwg</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>---------------------------</div><div>Wael Nasr</div><div>SVP - TLDVIilla LLC</div><div><a href="http://icannwiki.com/Wael_Nasr" target="_blank">http://icannwiki.com/Wael_Nasr</a></div><div><div><a href="http://www.linkedin.com/in/nasrwael" target="_blank">http://www.linkedin.com/in/nasrwael</a></div><div>US Office : +1 209 682 5144.</div><div>Bahrain mobile :+973 393 16891</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>