<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">While the root has a mandate to be more
restrictive, and therefore excludes digits and hyphens, there
would be a benefit of some consistency in practice between second
level and the root: in particular for zones that support entire
scripts and / or multiple scripts.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">There's been a lot of thought put into
how to make those scenarios safe (and unbiased towards particular
languages) in the root that would be useful for the second level
to take recognition of (and to apply them after accounting for
needed extensions like digits).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The current practice in some TLDs to
throw open registrations to any PVALID code points isn't really
helpful. You might call it either lazy, because defining sensible
restrictions takes work, or greedy, because restrictions to reduce
the available name space; except generally, they are designed not
to prevent legitimate registrations of useful labels (that is
those, that most users for at least some language can read/type
and that are not malicious registrations of look-alikes).<br>
</div>
<div class="moz-cite-prefix">A./<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 5/13/2019 8:58 AM, Tan Tanaka,
Dennis via UA-discuss wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E9F26ED2-67F9-4F0B-9220-D59AD6694D34@verisign.com">
<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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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";}
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;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}
span.EmailStyle20
{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]-->
<div class="WordSection1">
<p class="MsoNormal">Thanks for the publicity Ajay <span
style="font-family:"Apple Color Emoji"">
☺</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The draft recommendations should come out
very soon for public comments. However, our work is limited to
the use of the RZ-LGR. As the name suggests, the RZ-LGR’s
purpose is to validate top level domain labels. This thread is
about the ICANN IDN Implementation Guidelines which is geared
towards second level domain names.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Dennis<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span
style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">UA-discuss
<a class="moz-txt-link-rfc2396E" href="mailto:ua-discuss-bounces@icann.org"><ua-discuss-bounces@icann.org></a> on behalf of "Dr.
Ajay Data" <a class="moz-txt-link-rfc2396E" href="mailto:ajay@data.in"><ajay@data.in></a><br>
<b>Date: </b>Saturday, May 11, 2019 at 11:42 PM<br>
<b>To: </b><a class="moz-txt-link-rfc2396E" href="mailto:UA-discuss@icann.org">"UA-discuss@icann.org"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:ua-discuss@icann.org"><ua-discuss@icann.org></a>, John Levine
<a class="moz-txt-link-rfc2396E" href="mailto:john.levine@standcore.com"><john.levine@standcore.com></a><br>
<b>Subject: </b>[EXTERNAL] Re: [UA-discuss] GNSO
requested deferral of IDN Guidelines 4.0 Vote - CPH /
Registrants impact<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">ICANN
Board asked the ICANN community to recommend how to
technically apply the RZ-LGR in a harmonized way for existing
and future IDN ccTLDs and gTLDs.<br>
<br>
This Study Group was formed and chaired by Dennis Tan and the
document will be out soon for public comment.
<br>
<br>
This will answer many of the doubts and queries.<br>
<br>
Thanks<br>
<br>
AD<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">On May 12, 2019
8:02:41 AM GMT+05:30, John Levine
<a class="moz-txt-link-rfc2396E" href="mailto:john.levine@standcore.com"><john.levine@standcore.com></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">
<pre style="margin-left:.5in">In article <a class="moz-txt-link-rfc2396E" href="mailto:54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com"><54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com></a> you write:<o:p></o:p></pre>
<blockquote style="border:none;border-left:solid #729FCF
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in;margin-bottom:6.0pt">
<pre style="margin-left:.5in">Anytime you change the registration policies for an existing registry,
you will have to figure out how to grandfather existing, delegated
labels (if any).<o:p></o:p></pre>
</blockquote>
<pre style="margin-left:.5in">
The LGRs for several existing TLDS have changed, and .com and .net
have some IDNs that predate any LGRs. The rule seems to be that you
can renew whatever you have forever, but if it expires and it's not
valid under the new rule, nobody can reregister it.
I'm not sure how much of a problem this is in practice. When I went
through and looked at all of the IDNs in gTLDs including all the old
ones, the number that were grandfathered was quite small, well under
1% of the total. By percentages it seemed to be more of a problem
that some new TLDs aren't following their own existing rules.
R's,
John<o:p></o:p></pre>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br>
-- <br>
Sent from my Android device with XGenPlus.<span
style="border:solid windowtext 1.0pt;padding:0in"><img
style="width:.3333in;height:.3333in" id="_x0000_i1025"
src="cid:~WRD000.jpg" alt="Image removed by sender."
moz-do-not-send="true" width="32" height="32"></span>
<o:p></o:p></p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>