<div dir="auto">[I am speaking entirely in my personal capacity here and the forwarded email]<div dir="auto"><br></div><div dir="auto">The letter does exist, and it would seem it was considered.  Rather than pivot the point in that direction, what about the points I raise?  These should be in focus.</div><div dir="auto"><br></div><div dir="auto">The outcome in the time since my original email was a deferal, and current procedural step is a GNSO Council review with a small group of interested parties to determine if this is something that bypassed and needs a PDP, and under contemplation are different options forward such as splitting cc/g variant top level matters.</div><div dir="auto"><br></div><div dir="auto">The concern I was voicing was entirely about backward compatibility - focused mostly about second level changes that may break or invalidate legacy innovators registrations.  </div><div dir="auto"><br></div><div dir="auto">Standards evolution needs to have backward compatibility.  New standards have to ensure some manner to continue retroactive support for prior standards.</div><div dir="auto"><br></div><div dir="auto">Why?  Ĺet us be painfully self-authentic about IDN here... it holds potential, and can do big things, but the very pragmatic truth is that it requires developers to do extra stuff to make it work. </div><div dir="auto"><br></div><div dir="auto">Introducing IDN support into project development is typically not a priority when weighed against other projects or features within most development teams.  It adds scope and often needs specialized expertise, neither of which reduce cost.</div><div dir="auto"><br></div><div dir="auto">If we are telling developers and registrants to take the time, money, etc. to prioritize IN and build something using today's standard... it needs to be sonething there is a reasonable degree of confidence in.</div><div dir="auto"><br></div><div dir="auto">Here is an example. IDNA2003 vs IDNA2008 changed variant support and it rendered some changes that developers still lament.  </div><div dir="auto"><br></div><div dir="auto">If you are someone who went to embrace IDN, with all of its development overheads I describe, and in 2003 registered a perfectly valid registration and started using it, and 5 years later in 2008 you wanted to register (say for brand protection purposes in this example) that string, it may or may not be possible.  </div><div dir="auto"><br></div><div dir="auto">The standard evolution may have meant it became a variant of another string or worse was rendered invalid.  That is a bad experience.</div><div dir="auto"><br></div><div dir="auto">In the case that the name was impacted, that perfectly valid registration from 2003 becomes harder and harder to use due to development being focused upon 2008's standard.</div><div dir="auto"><br></div><div dir="auto">We certainly learn as we go, and in parallel the Unicode Standard, security concerns, browsers, ca, other things evolve over time.</div><div dir="auto"><br></div><div dir="auto">Invalidating a registration or otherwise failing to provide reliability and stability completely undermines institutional confidence.</div><div dir="auto"><br></div><div dir="auto">As we evolve the standards, if we fail to support those who innovate as we evolve, do we undermine confidence?</div><div dir="auto"><br></div><div dir="auto"> Is it a reasonable expectation that those who would take on that extra overhead of IDN adoption do so where we are providing evidence of later potentially breaking it?</div><div dir="auto"><br></div><div dir="auto">Let's be honest, they will likely just find lower risk areas to focus their resources and skip it.</div><div dir="auto"><br></div><div dir="auto">-J</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 11, 2019, 05:39 Dusan Stojicevic <<a href="mailto:dusan@dukes.in.rs">dusan@dukes.in.rs</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Dear Roberto,<div dir="auto"><br></div><div dir="auto">As far as I know, there's no such report. More on that - most of the IDN ccTLDs are not even considering variants. They are not obligated to do that (in fact, not obligated to anything what ICANN try to regulate), and Guidelines are just recommendation for them.</div><div dir="auto">Guidelines are obligation for IDN gTLDs, New gTLDs and new applications for IDN TLDs. And that's how they manage variants.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Dusan</div><div dir="auto"><br></div><div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pet, 10. maj 2019. 23:31 Roberto Gaetano <<a href="mailto:roberto_gaetano@hotmail.com" target="_blank" rel="noreferrer">roberto_gaetano@hotmail.com</a>> je napisao/la:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;line-break:after-white-space">
Hi all.
<div>This email from Jothan makes a good point about the impact caused by changing the standard about managing variants.</div>
<div>I was wondering whether we have a report on how variants are managed by different IDN registries.</div>
<div>Somebody can point me to such a source?</div>
<div>Thanks,</div>
<div>Roberto</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On 30.04.2019, at 23:27, Jothan Frakes <<a href="mailto:jothan@gmail.com" rel="noreferrer noreferrer" target="_blank">jothan@gmail.com</a>> wrote:</div>
<br class="m_-518490196878003804m_-7167153382668342884Apple-interchange-newline">
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
The GNSO just sent a letter to request that the vote on adoption of the IDN Guidelines 4.0 be deferred </div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
There is some UA pain that will come from these Guidelines we should be completely aware of.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
It is important to identify the manner in which standards can impact the contracted parties, such as the Registries and Registrars, but getting even further out the supply chain into registrants and Internet users, there are some impacts to them as well as
 their audiences.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
If the new standard causes something that was a separate registration to become a variant of another registration, or invalidates an existing registration, this is a bad outcome for the innovators, developers, and early patrons that supported the internationalization
 of the namespace.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
Part of what the objective of UA is, to my reckoning, is to increase engagement and support of coding projects that will require adoption of standards that may not immediately hold levels of RoI to them, and they are looking for reasons not to do them.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
These new guidelines are good - and needed - they are the result of many people's hard work, time and wisdom, and address many solutions.  The approach of pushing these out is problematic.  Further, there seems no recourse for those (even if statistically small)
 who may be impacted adversely, lose their domain, or have it be invalidated (and thus REVERSE their UA experience)<br>
<br>
There is potential impact to existing TLDs, and most notably to registrants of second level names where there are registrations using former standards that become unsupported or invalidated.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
A very important challenge we face with the UA effort is inspiring developers to implement IDN and EAI as we help globalize the Internet through our work.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
IF the approach on standards will be to invalidate some portion of the community of registrations like this, there must be attention to how this impacts existing innovators.  </div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
Innovators worked to drive the standards and increase awareness - and the invalidation or deprecation of a registration that someone has carried for a number of years (some are 15+ years) is the precise opposite of a reward for early support, and it is going
 to send a very loud message to developers.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
I believe that further review is needed by registries on the technical impacts of the changes, but any delay can help ICANN and the community address the disenfranchisement factor.</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
This should be important to UASG - we need developers to embrace the additional effort that they have to invest in their work to consider IDN, EAI and other things.<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
-Jothan</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">
<br>
</div>
<div>
<div dir="ltr" class="m_-518490196878003804m_-7167153382668342884gmail_signature" data-smartmail="gmail_signature">Jothan Frakes<br>
+1.206-355-0230 tel<br>
+1.206-201-6881 fax</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div></div></div>
</blockquote></div>