GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact
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
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@gmail.com<mailto:jothan@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
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@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@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
[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@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@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@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
Delaying the IDN Guidelines will just mean more registries will register more "non-standard" labels and make it harder to implement something that's reasonably secure for everyone. Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any). My understanding was that the guidelines were intended primarily for newly established registries, but I'd love to find out whether this understanding is wrong for some reason. The GNSO represents the "ccTLDs" and they would just love to continue with "innovations" like emoji domain names. I would love to see some concrete cases of existing registrations for ccTLDs that are reasonable labels that would be impacted. Anyone know? A./ On 5/10/2019 2:31 PM, Roberto Gaetano wrote:
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@gmail.com <mailto:jothan@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
The ccNSO is a membership body of ccTLDs. The gNSO has a variety of participants – including registries – but not generally ccTLDs. D From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Asmus Freytag Sent: Sunday, 12 May 2019 8:58 AM To: ua-discuss@icann.org Subject: Re: [UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact Delaying the IDN Guidelines will just mean more registries will register more "non-standard" labels and make it harder to implement something that's reasonably secure for everyone. Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any). My understanding was that the guidelines were intended primarily for newly established registries, but I'd love to find out whether this understanding is wrong for some reason. The GNSO represents the "ccTLDs" and they would just love to continue with "innovations" like emoji domain names. I would love to see some concrete cases of existing registrations for ccTLDs that are reasonable labels that would be impacted. Anyone know? A./ On 5/10/2019 2:31 PM, Roberto Gaetano wrote: 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@gmail.com<mailto:jothan@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
In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write:
Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).
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
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. This Study Group was formed and chaired by Dennis Tan and the document will be out soon for public comment. This will answer many of the doubts and queries. Thanks AD On May 12, 2019 8:02:41 AM GMT+05:30, John Levine <john.levine@standcore.com> wrote:
In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write:
Anytime you change the registration policies for an existing registry,
you will have to figure out how to grandfather existing, delegated labels (if any).
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
-- Sent from my Android device with XGenPlus.
Thanks for the publicity Ajay ☺ 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. Dennis From: UA-discuss <ua-discuss-bounces@icann.org> on behalf of "Dr. Ajay Data" <ajay@data.in> Date: Saturday, May 11, 2019 at 11:42 PM To: "UA-discuss@icann.org" <ua-discuss@icann.org>, John Levine <john.levine@standcore.com> Subject: [EXTERNAL] Re: [UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact 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. This Study Group was formed and chaired by Dennis Tan and the document will be out soon for public comment. This will answer many of the doubts and queries. Thanks AD On May 12, 2019 8:02:41 AM GMT+05:30, John Levine <john.levine@standcore.com> wrote: In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write: Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any). 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 -- Sent from my Android device with XGenPlus.[Image removed by sender.]
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. 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). 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). A./ On 5/13/2019 8:58 AM, Tan Tanaka, Dennis via UA-discuss wrote:
Thanks for the publicity Ajay ☺
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.
Dennis
*From: *UA-discuss <ua-discuss-bounces@icann.org> on behalf of "Dr. Ajay Data" <ajay@data.in> *Date: *Saturday, May 11, 2019 at 11:42 PM *To: *"UA-discuss@icann.org" <ua-discuss@icann.org>, John Levine <john.levine@standcore.com> *Subject: *[EXTERNAL] Re: [UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact
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.
This Study Group was formed and chaired by Dennis Tan and the document will be out soon for public comment.
This will answer many of the doubts and queries.
Thanks
AD
On May 12, 2019 8:02:41 AM GMT+05:30, John Levine <john.levine@standcore.com> wrote:
In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write:
Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).
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
-- Sent from my Android device with XGenPlus.Image removed by sender.
[speaking entirely in a personal capacity here] I strongly recommend that attention needs to be put towards how the registrants, as well as the provider channel are impacted, especially with respect to the impact on second level (or deeper) registration policies, and this not be trivialized. Confidence and Trust are a large component of attracting better adoption and driving forward UA projects. The user journey of a registrant needs a lot of consideration here. Also, commercially interested parties like registrars get to have very uncomfortable interaction with registrants who suddenly may have a domain that is hobbled or invalidated. Software developers are looking at this as well, determining how (and if) to support IDN and UA. 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.
That was some helpful measurement. Building upon this, the grandfathered registrant-folk were probably a mix of innovators and entrepreneurs (or both). But the fact that they invested time and money, and have renewed these registrations over the span of time indicates that they are interested in the stuff we're hoping to grow adoption and acceptance of. Hopefully, if we can get more universal acceptance/awareness in communities that could benefit from them, the total sum of all IDN registrations we currently have will be 1% of some future number. My hope is that some future standard update at that point in time not break that statistically insignificant user pool, and this is what developers, IT management, and those who control product cycles where UA can be introduced are considering when choosing what to have teams focus on in their road-maps. Anytime you change the registration policies for an existing registry,
you will have to figure out how to grandfather existing, delegated labels (if any).
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.
Grand-fathering the registrations is one aspect of addressing these things. This means a registrant has the option to continue to pay for the domain and keep using it, which is good. The challenge comes with standards updates that gradually (or suddenly) diminish the ability to use that name to the level of benefit that was present at the time of registration. A better way to preserve confidence might be to buy them back or offer a path to updated standards for those registrants in a way that is reasonable and acceptable to them. Developers and development leaders will look closely at how this is addressed, as UA projects are harder, with more testing and QA, as well as other specializations which introduce greater scope than other projects that might have clearer profit/benefit or prioritization. The manner in which we address legacy registrations will have an impact on the success of the UA -Jothan On Sat, May 11, 2019 at 7:32 PM John Levine <john.levine@standcore.com> wrote:
In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write:
Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).
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
For sure, if I were an IDN registrant and experienced rejection of my domain name (or email address) by some application because all of a sudden it becomes a “forbidden” variant, I would be seriously annoyed. It is true that the affected domain names are probably a rounding error compared to the hundreds of millions domain names, but it would nevertheless (further) reduce confidence in IDNs - and this is something that we really do not need. Cheers, Roberto On 13.05.2019, at 07:25, Jothan Frakes <jothan@jothan.com<mailto:jothan@jothan.com>> wrote: [speaking entirely in a personal capacity here] I strongly recommend that attention needs to be put towards how the registrants, as well as the provider channel are impacted, especially with respect to the impact on second level (or deeper) registration policies, and this not be trivialized. Confidence and Trust are a large component of attracting better adoption and driving forward UA projects. The user journey of a registrant needs a lot of consideration here. Also, commercially interested parties like registrars get to have very uncomfortable interaction with registrants who suddenly may have a domain that is hobbled or invalidated. Software developers are looking at this as well, determining how (and if) to support IDN and UA. 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. That was some helpful measurement. Building upon this, the grandfathered registrant-folk were probably a mix of innovators and entrepreneurs (or both). But the fact that they invested time and money, and have renewed these registrations over the span of time indicates that they are interested in the stuff we're hoping to grow adoption and acceptance of. Hopefully, if we can get more universal acceptance/awareness in communities that could benefit from them, the total sum of all IDN registrations we currently have will be 1% of some future number. My hope is that some future standard update at that point in time not break that statistically insignificant user pool, and this is what developers, IT management, and those who control product cycles where UA can be introduced are considering when choosing what to have teams focus on in their road-maps. Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any). 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. Grand-fathering the registrations is one aspect of addressing these things. This means a registrant has the option to continue to pay for the domain and keep using it, which is good. The challenge comes with standards updates that gradually (or suddenly) diminish the ability to use that name to the level of benefit that was present at the time of registration. A better way to preserve confidence might be to buy them back or offer a path to updated standards for those registrants in a way that is reasonable and acceptable to them. Developers and development leaders will look closely at how this is addressed, as UA projects are harder, with more testing and QA, as well as other specializations which introduce greater scope than other projects that might have clearer profit/benefit or prioritization. The manner in which we address legacy registrations will have an impact on the success of the UA -Jothan On Sat, May 11, 2019 at 7:32 PM John Levine <john.levine@standcore.com<mailto:john.levine@standcore.com>> wrote: In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com<mailto:54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com>> you write:
Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).
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
On Sun, 12 May 2019, Jothan Frakes wrote:
That was some helpful measurement. Building upon this, the grandfathered registrant-folk were probably a mix of innovators and entrepreneurs (or both). But the fact that they invested time and money, and have renewed these registrations over the span of time indicates that they are interested in the stuff we're hoping to grow adoption and acceptance of.
Actually, all of the grandfathered stuff I saw was junk. It has characters like degree and euro signs and punctuation. I spot checked a bunch of them to see if they resolved and all of the ones that did went to a generic parking or for sale page. The most notable change has been that the ß eszett is now allowed in German names. There are some active web sites with ß names and I agree it would be bad if they stopped working (keeping in mind that some browsers still use old IDNA2003 mappings so there are browsers where they don't work now.) Not wearing my UA hat this tells me that it continues to be a bad idea to have live variant names in the DNS as opposed to delegating one and blocking the rest. If it wasn't active in the first place, you can't break it. Regards, John Levine, john.levine@standcore.com Standcore LLC
The manner in which we address legacy registrations will have an impact on the success of the UA.
While it's important to keep in mind the user experience, we should also consider the impact of non harmonized systems. As much as IDNA20008 has problems, it still resolves some key issues in IDNA2003. While it's a straightforward argument to say no variants should be allowed on the DNS, the reality in many linguistic locales is that variants are a part of everyday life. Not just in the Han script, but in Indic and Arabic scripts, among others. We can't wish them away, nor do we have the luxury of saying the DNS wasn't designed for it, so it shall never support it. Harmonization of the rules of usage, combined with what an appropriate and universal user experience ought to be are important foundations for the universal acceptance of internationalized domain names. Ram On Mon, May 13, 2019, 12:26 AM Jothan Frakes <jothan@jothan.com> wrote:
[speaking entirely in a personal capacity here]
I strongly recommend that attention needs to be put towards how the registrants, as well as the provider channel are impacted, especially with respect to the impact on second level (or deeper) registration policies, and this not be trivialized.
Confidence and Trust are a large component of attracting better adoption and driving forward UA projects.
The user journey of a registrant needs a lot of consideration here. Also, commercially interested parties like registrars get to have very uncomfortable interaction with registrants who suddenly may have a domain that is hobbled or invalidated. Software developers are looking at this as well, determining how (and if) to support IDN and UA.
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.
That was some helpful measurement. Building upon this, the grandfathered registrant-folk were probably a mix of innovators and entrepreneurs (or both). But the fact that they invested time and money, and have renewed these registrations over the span of time indicates that they are interested in the stuff we're hoping to grow adoption and acceptance of.
Hopefully, if we can get more universal acceptance/awareness in communities that could benefit from them, the total sum of all IDN registrations we currently have will be 1% of some future number.
My hope is that some future standard update at that point in time not break that statistically insignificant user pool, and this is what developers, IT management, and those who control product cycles where UA can be introduced are considering when choosing what to have teams focus on in their road-maps.
Anytime you change the registration policies for an existing registry,
you will have to figure out how to grandfather existing, delegated labels (if any).
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.
Grand-fathering the registrations is one aspect of addressing these things. This means a registrant has the option to continue to pay for the domain and keep using it, which is good. The challenge comes with standards updates that gradually (or suddenly) diminish the ability to use that name to the level of benefit that was present at the time of registration.
A better way to preserve confidence might be to buy them back or offer a path to updated standards for those registrants in a way that is reasonable and acceptable to them.
Developers and development leaders will look closely at how this is addressed, as UA projects are harder, with more testing and QA, as well as other specializations which introduce greater scope than other projects that might have clearer profit/benefit or prioritization.
The manner in which we address legacy registrations will have an impact on the success of the UA
-Jothan
On Sat, May 11, 2019 at 7:32 PM John Levine <john.levine@standcore.com> wrote:
In article <54666ffb-2773-97e9-10d0-f6c0d4afa8aa@ix.netcom.com> you write:
Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).
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
On Mon, 13 May 2019, Ram Mohan wrote:
While it's a straightforward argument to say no variants should be allowed on the DNS, the reality in many linguistic locales is that variants are a part of everyday life. Not just in the Han script, but in Indic and Arabic scripts, among others. We can't wish them away, nor do we have the luxury of saying the DNS wasn't designed for it, so it shall never support it.
I think there's a large gap between "many writing systems can write the same thing in different ways" and "those different ways should be in the DNS." It's easy to see why you'd block variants, but particularly given the utter lack of tools to provision them, and no interest in creating those tools, hard to see why you'd delegate them. Regards, John Levine, john.levine@standcore.com Standcore LLC
I agree there's a large provisioning gap. My experience in China, Japan, India, the Gulf states etc. is an inherent local belief that the internet will follow real life in terms of use of scripts. And a lot of impatience with technical reasons why it's not the most feasible thing. On Mon, May 13, 2019, 12:08 PM John Levine <john.levine@standcore.com> wrote:
On Mon, 13 May 2019, Ram Mohan wrote:
While it's a straightforward argument to say no variants should be allowed on the DNS, the reality in many linguistic locales is that variants are a part of everyday life. Not just in the Han script, but in Indic and Arabic scripts, among others. We can't wish them away, nor do we have the luxury of saying the DNS wasn't designed for it, so it shall never support it.
I think there's a large gap between "many writing systems can write the same thing in different ways" and "those different ways should be in the DNS."
It's easy to see why you'd block variants, but particularly given the utter lack of tools to provision them, and no interest in creating those tools, hard to see why you'd delegate them.
Regards, John Levine, john.levine@standcore.com Standcore LLC
I agree there's a large provisioning gap. My experience in China, Japan, India, the Gulf states etc. is an inherent local belief that the internet will follow real life in terms of use of scripts. And a lot of impatience with technical reasons why it's not the most feasible thing.
I don't understand what "the internet will follow real life in terms of use of scripts" means, and in particular how it would be inconsistent with registering one variant and blocking the rest. You can use whatever you want in your web site, your mail, and everything else. But for your identifier, pick one. R's, John
On Mon, May 13, 2019, 12:08 PM John Levine <john.levine@standcore.com> wrote:
On Mon, 13 May 2019, Ram Mohan wrote:
While it's a straightforward argument to say no variants should be allowed on the DNS, the reality in many linguistic locales is that variants are a part of everyday life. Not just in the Han script, but in Indic and Arabic scripts, among others. We can't wish them away, nor do we have the luxury of saying the DNS wasn't designed for it, so it shall never support it.
I think there's a large gap between "many writing systems can write the same thing in different ways" and "those different ways should be in the DNS."
It's easy to see why you'd block variants, but particularly given the utter lack of tools to provision them, and no interest in creating those tools, hard to see why you'd delegate them.
Regards, John Levine, john.levine@standcore.com Standcore LLC
Regards, John Levine, john.levine@standcore.com Standcore LLC
On 5/13/2019 12:59 PM, John Levine wrote:
I don't understand what "the internet will follow real life in terms of use of scripts" means, and in particular how it would be inconsistent with registering one variant and blocking the rest.
You can use whatever you want in your web site, your mail, and everything else. But for your identifier, pick one.
R's, John
Not always as easy and free of other consequences. See my other message. A./
On 5/13/2019 10:08 AM, John Levine wrote:
On Mon, 13 May 2019, Ram Mohan wrote:
While it's a straightforward argument to say no variants should be allowed on the DNS, the reality in many linguistic locales is that variants are a part of everyday life. Not just in the Han script, but in Indic and Arabic scripts, among others. We can't wish them away, nor do we have the luxury of saying the DNS wasn't designed for it, so it shall never support it.
I think there's a large gap between "many writing systems can write the same thing in different ways" and "those different ways should be in the DNS."
It's easy to see why you'd block variants, but particularly given the utter lack of tools to provision them, and no interest in creating those tools, hard to see why you'd delegate them.
John, sorry, I'm with Ram on this one. Where I agree with you is on the beneficial nature of blocked variants. They are a cheap and underused tool to limit the attack surface for deceptive registrations. However, once you block a variant, you take away the option for applicants to apply for the variant even if they have registered the original label. Where variants are unrelated, that's not an issue. But in many scripts you have situations where different keyboards, for example, may have one of the variants, but not the other. And where both variants are used for the same letter. By blocking such variants, you exclude one community from "reaching" any label registered for another one. We don't really have that situation in the Latin script, not even with European languages. The closest you can get is that Danish uses "ø" for the letter for which Swedish uses "ö". However, the same word, like the name of the Danish capital, is often spelled differently elsewhere in the word, e.g. Köpenhamm instead of København. (Therefore, Copenhagen can simply apply for all three spellings, and additional ones as well - such as the German spelling; even if the two code points were variants, the labels are not). That reduces the case for making these two letters variants of each other. However, between Arabic and Persian, you'll have cases where geographic names differ ONLY by such local variant use. You could target only one community. Not allowing someone to register both variants in this situation causes just as many problems as ignoring the variant relation altogether and letting an unrelated party register the variant. There are many similar examples, and the best way to handle them is to support allocatable variants. They still block the access to registration of the variant label by unrelated parties, but allow one applicant to register both. With the new LGR format, you can express some further constraints so that only a limited number of variant *labels* can be allocated. For example, if you have a pair of code points that are variants, and a pair of labels that contain 2 copies of each (in matching positions) you would normally get a set of 4 variant labels. An easy way to constrain that is to limit all variants to be from the same subset (e.g. either all Persian, or all Arabic). Allocatable variants still leave it to the discretion of the applicant as to whether to apply for more than one variant. Some people prefer automatic activation, where all applicant would receive all variants. There may be some cases where that would match the overall users' expectations. For example, there are three sets of digits used with the Arabic script, each being in "native" use in a different region. Two of these sets even share many digit forms. Since any numbers these digits represent are obviously the same, and in some cases, users cannot tell which set of digits is used, forcing activation may be justified. No matter how you come down on that last example, there's no escaping the need to deal with scripts that do have such variants. The LGR format in RFC 7940 is making a start in letting you express more of your registry policies in a machine-readable format that was possible before (even with the earlier IDN table format extensions for Chinese and Arabic). Time to put some of the other tools into place. A./
In article <e73833f6-0fec-4143-b3d5-6f4c7b68aa1e@ix.netcom.com> you write:
By blocking such variants, you exclude one community from "reaching" any label registered for another one.
OK, I can believe it in principle.
Time to put some of the other tools into place.
If the people who allegedly want the variant names put some effort or money into tools to make them work, I would be considerably more sympathetic to claims that they are important. It would not be very hard to write tools to take a set of variant names and create DNS records and configure popular mail or web servers to make them work as aliases, and anyone could have done so at some point in the past decade, but as far as I am aware, nobody has. R's, John
participants (11)
-
Asmus Freytag -
Asmus Freytag (c)
-
Don Hollander -
Dr. Ajay Data -
Dusan Stojicevic -
John Levine -
Jothan Frakes -
Jothan Frakes -
Ram Mohan -
Roberto Gaetano -
Tan Tanaka, Dennis