Latin Script Diacritics PDP Working Group: Difference between revisions

(2 intermediate revisions by the same user not shown)

Line 71:

The group also discussed the risk of conflating "Latin diacritic sets" (ASCII plus associated Latin-diacritic labels handled under the PDP) with IDN variant sets defined in the RZ-LGR. In late 2025 meetings, WG discussions explored how combining Latin-diacritic sets and IDN variant sets could lead to complex multi-label relationships that would need careful SSR and policy analysis.<ref name="lsd-confluence"></ref>

=== String Similarity and Exception Mechanisms ===

Another major area of work has been understanding how existing string similarity rules in the new gTLD program, as affirmed by the Subsequent Procedures PDP, would apply to ASCII/diacritic pairs, and what kind of exception or special mechanism might be needed to enable same-entity operation without undermining the goal of minimizing user confusion.<ref name="lsd-final-ir"></ref><ref name="lsd-prelim-ir"></ref>

The WG has looked at the ccTLD precedent for ''.eu''/''.ευ'' (an exception procedure tied to same-entity operation and specific mitigation measures) as one possible model, while recognising that gTLD policy may require a different set of conditions and could not simply copy the ccTLD solution.<ref name="lsd-prelim-ir"></ref>

=== Relationship to EPDP on IDNs and Universal Acceptance ===

The WG relies on the EPDP on IDNs Phases 1 and 2 as a baseline for understanding "same entity" relationships and variant management across scripts. It has worked through EPDP recommendations to determine which can be applied directly to Latin-diacritic cases, which might inspire Latin-specific adaptations, and where distinct rules may be needed because diacritics are not variants under the RZ-LGR.<ref name="lsd-final-ir"></ref><ref name="apr-ldpdp"></ref>

Universal Acceptance considerations also feature in the deliberations. For many end users and service providers, diacritic-based labels still face support constraints in software and systems; the PDP therefore needs to balance the linguistic correctness and identity benefits of diacritics with UA realities and potential user-experience risks when ASCII and diacritic labels coexist.<ref name="lsd-prelim-ir"></ref><ref name="lsd-pc"></ref>

=== Stress Testing and Case Studies ===

By [[ICANN 84]] (October 2025), the WG had begun using stress-test scenarios and case studies to examine edge cases where ASCII, Latin-diacritic labels and IDN variants might interact, including situations where multiple scripts and label sets could create complex relationships. These stress tests are used to refine preliminary recommendations and ensure that any policy framework can handle difficult cases without unintended consequences for security, stability, or user trust.<ref name="lsd-confluence"></ref><ref name="apr-ldpdp"></ref>

== Community Input and Perspectives ==

The public comment forum on the Preliminary Issue Report attracted contributions from registry operators, registrars, At-Large structures, individual community members, and other stakeholders. A large majority of commenters supported initiating the PDP, highlighting benefits for linguistic accuracy, cultural representation, and parity for communities using Latin script diacritics. A smaller number of submissions raised concerns about potential phishing and confusion risks, or questioned whether the issue justified a full PDP.<ref name="lsd-pc"></ref>

Regional and community perspectives, such as those documented in the APRALO Bytes update of November 2025, have emphasized that Latin-diacritic issues have been a long-standing concern, especially in francophone and other communities where diacritics are integral to language. These updates also underscore the expectation that any eventual policy should be narrowly tailored, technically robust, and closely aligned with IDN variant and UA work streams.<ref name="apr-ldpdp"></ref>

== Status and Timeline ==

As of late 2025, the Latin Script Diacritics PDP Working Group had:

* completed its initial pass through the EPDP on IDNs recommendations to assess their applicability to Latin-diacritic cases;

* developed and refined a framework for distinguishing Latin-diacritic sets from IDN variant sets and for scoping eligible ASCII/diacritic pairs; and

* begun drafting preliminary recommendations and stress-testing them through case studies and WG discussions.<ref name="lsd-confluence"></ref><ref name="apr-ldpdp"></ref>

According to an APRALO status update in November 2025, the WG anticipated publishing an Initial Report for public comment in early 2026 (with a target of January 2026) and delivering a Final Report to the GNSO Council around August 2026, subject to the pace of deliberations and community feedback.<ref name="apr-ldpdp"></ref>

== References ==

@@ Line 71: / Line 71: @@
 The group also discussed the risk of conflating "Latin diacritic sets" (ASCII plus associated Latin-diacritic labels handled under the PDP) with IDN variant sets defined in the RZ-LGR. In late 2025 meetings, WG discussions explored how combining Latin-diacritic sets and IDN variant sets could lead to complex multi-label relationships that would need careful SSR and policy analysis.<ref name="lsd-confluence"></ref>
+=== String Similarity and Exception Mechanisms ===
+Another major area of work has been understanding how existing string similarity rules in the new gTLD program, as affirmed by the Subsequent Procedures PDP, would apply to ASCII/diacritic pairs, and what kind of exception or special mechanism might be needed to enable same-entity operation without undermining the goal of minimizing user confusion.<ref name="lsd-final-ir"></ref><ref name="lsd-prelim-ir"></ref>
+The WG has looked at the ccTLD precedent for ''.eu''/''.ευ'' (an exception procedure tied to same-entity operation and specific mitigation measures) as one possible model, while recognising that gTLD policy may require a different set of conditions and could not simply copy the ccTLD solution.<ref name="lsd-prelim-ir"></ref>
+=== Relationship to EPDP on IDNs and Universal Acceptance ===
+The WG relies on the EPDP on IDNs Phases 1 and 2 as a baseline for understanding "same entity" relationships and variant management across scripts. It has worked through EPDP recommendations to determine which can be applied directly to Latin-diacritic cases, which might inspire Latin-specific adaptations, and where distinct rules may be needed because diacritics are not variants under the RZ-LGR.<ref name="lsd-final-ir"></ref><ref name="apr-ldpdp"></ref>
+Universal Acceptance considerations also feature in the deliberations. For many end users and service providers, diacritic-based labels still face support constraints in software and systems; the PDP therefore needs to balance the linguistic correctness and identity benefits of diacritics with UA realities and potential user-experience risks when ASCII and diacritic labels coexist.<ref name="lsd-prelim-ir"></ref><ref name="lsd-pc"></ref>
+=== Stress Testing and Case Studies ===
+By [[ICANN 84]] (October 2025), the WG had begun using stress-test scenarios and case studies to examine edge cases where ASCII, Latin-diacritic labels and IDN variants might interact, including situations where multiple scripts and label sets could create complex relationships. These stress tests are used to refine preliminary recommendations and ensure that any policy framework can handle difficult cases without unintended consequences for security, stability, or user trust.<ref name="lsd-confluence"></ref><ref name="apr-ldpdp"></ref>
+== Community Input and Perspectives ==
+The public comment forum on the Preliminary Issue Report attracted contributions from registry operators, registrars, At-Large structures, individual community members, and other stakeholders. A large majority of commenters supported initiating the PDP, highlighting benefits for linguistic accuracy, cultural representation, and parity for communities using Latin script diacritics. A smaller number of submissions raised concerns about potential phishing and confusion risks, or questioned whether the issue justified a full PDP.<ref name="lsd-pc"></ref>
+Regional and community perspectives, such as those documented in the APRALO Bytes update of November 2025, have emphasized that Latin-diacritic issues have been a long-standing concern, especially in francophone and other communities where diacritics are integral to language. These updates also underscore the expectation that any eventual policy should be narrowly tailored, technically robust, and closely aligned with IDN variant and UA work streams.<ref name="apr-ldpdp"></ref>
+== Status and Timeline ==
+As of late 2025, the Latin Script Diacritics PDP Working Group had:
+* completed its initial pass through the EPDP on IDNs recommendations to assess their applicability to Latin-diacritic cases;
+* developed and refined a framework for distinguishing Latin-diacritic sets from IDN variant sets and for scoping eligible ASCII/diacritic pairs; and
+* begun drafting preliminary recommendations and stress-testing them through case studies and WG discussions.<ref name="lsd-confluence"></ref><ref name="apr-ldpdp"></ref>
+According to an APRALO status update in November 2025, the WG anticipated publishing an Initial Report for public comment in early 2026 (with a target of January 2026) and delivering a Final Report to the GNSO Council around August 2026, subject to the pace of deliberations and community feedback.<ref name="apr-ldpdp"></ref>
 == References ==