هذا المحتوى متوفر فقط باللغة (أو اللغات)
Name: Registries Stakeholder Group (RySG)
Date: 15 Feb 2022
Original Public Comment: Additional Unicode Scripts for Support in Internationalized Domain Names
1. Based on the discussion in the report, should ICANN org support IDNs at the second level in the scripts identified as Limited Use by Unicode in UAX#31, where specific scripts will be finalized on a case-to-case basis using the criteria in the report?
No, Limited Use scripts at the second level should not be supported.
If you selected “no,” Limited Use scripts should not be supported for IDNs at the second level, please explain why? If you selected “yes,” are there any specific script(s) that should be clearly supported? If so, please list them and explain why?
The reason for this answer is because the "Additional Unicode Scripts for Support in Internationalized Domain Names'' suggests that ICANN will ONLY create LGRs for scripts that are classified as “recommended” and NOT create LGRs for scripts that are listed as “limited use” or “excluded”. This should not imply that those scripts listed as “limited use” or "excluded" may never be developed and/or deployed. Reference LGRs created by ICANN allow for a smoother process in Top Level applications i.e., Root Zone LGR, and second level script/language IDN table review process. However, if there is a script/language which is NOT supported in a Reference LGR created by ICANN, the registry operator should not be precluded from creating its own LGR, provided it is compliant with IDNA2008. In fact, many of the Reference LGRs that are developed by ICANN suggest that they may be edited. So on the premise of the question being SHOULD ICANN develop Reference LGRs for only recommended scripts, then it’s "yes" however any script which ICANN have not created an LGR for should NOT imply that a script is not "supported", much like a the moment there are a number of languages which ICANN have not developed a Reference LGR for however that does NOT imply that the language is not supported by ICANN or by a registry operator. Additionally, the Unicode Annex #31 has gone through several revisions since its inception; from time to time scripts have changed from one classification to another, therefore what is classified as “limited use” or “excluded” in one version might be reclassified in a future revision. So some consideration needs to be taken into account for this type of changes in the Technical Report.
2. Are there any changes needed in the criteria suggested to select the Limited Use scripts for support at the second level on a case-to-case basis?
No, a change is not needed in the existing criteria in the report.
3. Should ICANN support IDNs at the second level in scripts identified as Excluded by UAX#31 for identifiers?
No, Excluded scripts should not be supported at the second level, in line with Unicode recommendation in UAX#31.
Given the caution provided by Unicode in UAX#31, if Excluded scripts should still be supported, please explain why, and how the issues identified in UAX#31 and the report would be addressed or mitigated. Also indicate if the reason provided is generally applicable or only for the script(s) being specified.
No, the same sentiment applies as per the answer to question 1 with the follow-on explanation.
4. Are there any additional factors which should be considered by the Integration Panel, in addition to the findings of this report using the categorization provided in the UAX#31, for shortlisting the scripts for the Root Zone Label Generation Rules?
About implications of changes to an IDN table impacting existing registration:
The RySG acknowledges that Reference LGRs developed by ICANN may differ from existing IDN implementation offered by gTLDs. If and when a registry operator updates its IDN implementation with respect to a script or language, whether it conforms with an ICANN Reference LGR or not, there needs to be a decision made by the registry operator to reconcile the new rules vis-a-vis existing registration. The registry operator will need to decide whether to grandfather the existing registration or any other action that best meet the needs of its customers.
So it’s important to acknowledge that there may be a disruption to a registry operator’s operation and that the decision on how to manage these conflicts is the duty of the said registry operator and will be done so in the best interest of the registrars and registrants that they serve.
About next steps:
The RySG notes that ICANN intends that “[t]he recommendations for the second level will be implemented for the generic top-level domains (gTLDs). Future IDN table requests for gTLDs would only be considered for the scripts which are supported for the second level.” On this assertion, about how to move forward with the implementation, the RySG suggests that the appropriate pathway should balance the need to develop policies that take into account the views of the diverse registry operators, gTLDs and ccTLDs, with the benefits of enabling registry operators to avail themselves of the Technical Report’s recommendations. Both GNSO and ccNSO could be leveraged to develop a policy to address the recommendations in the Technical Report, taking into account the interests of a variety of stakeholders.
There needs to be a consideration for requesting ICANN to work on scripts that are classified as “limited use” or “excluded” if a reasonable justification is made by a registry operator, this way, communities that use those scripts are not excluded from representation on the internet from a domain name registration standpoint.
Summary of Submission
The Registries Stakeholder Group (RySG) provided feedback on the questions and made additional comments about implications of changes to an IDN table impacting existing registration and suggested next steps.