[UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact

Sat May 11 00:31:17 UTC 2019

[I am speaking entirely in my personal capacity here and the forwarded
email]

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.

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.

The concern I was voicing was entirely about backward compatibility -
focused mostly about second level changes that may break or invalidate
legacy innovators registrations.

Standards evolution needs to have backward compatibility.  New standards
have to ensure some manner to continue retroactive support for prior
standards.

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.

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.

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.

Here is an example. IDNA2003 vs IDNA2008 changed variant support and it
rendered some changes that developers still lament.

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.

The standard evolution may have meant it became a variant of another string
or worse was rendered invalid.  That is a bad experience.

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.

We certainly learn as we go, and in parallel the Unicode Standard, security
concerns, browsers, ca, other things evolve over time.

Invalidating a registration or otherwise failing to provide reliability and
stability completely undermines institutional confidence.

As we evolve the standards, if we fail to support those who innovate as we
evolve, do we undermine confidence?

 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?

Let's be honest, they will likely just find lower risk areas to focus their
resources and skip it.

-J

On Sat, May 11, 2019, 05:39 Dusan Stojicevic <dusan at dukes.in.rs> wrote:

> Dear Roberto,
>
> 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.
> Guidelines are obligation for IDN gTLDs, New gTLDs and new applications
> for IDN TLDs. And that's how they manage variants.
>
> Cheers,
> Dusan
>
>
>
>
> pet, 10. maj 2019. 23:31 Roberto Gaetano <roberto_gaetano at hotmail.com> je
> napisao/la:
>
>> Hi all.
>> This email from Jothan makes a good point about the impact caused by
>> changing the standard about managing variants.
>> I was wondering whether we have a report on how variants are managed by
>> different IDN registries.
>> Somebody can point me to such a source?
>> Thanks,
>> Roberto
>>
>>
>> On 30.04.2019, at 23:27, Jothan Frakes <jothan at gmail.com> wrote:
>>
>> The GNSO just sent a letter to request that the vote on adoption of the
>> IDN Guidelines 4.0 be deferred
>>
>> There is some UA pain that will come from these Guidelines we should be
>> completely aware of.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> -Jothan
>>
>>
>> Jothan Frakes
>> +1.206-355-0230 tel
>> +1.206-201-6881 fax
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190511/35d44927/attachment.html>