Latin Script Diacritics PDP Working Group: Difference between revisions

(5 intermediate revisions by the same user not shown)

Line 40:

The working group’s leadership is composed by:

* Chair: [[Michael Bauland]]

* Vice-chair: [[Mark W. Datysgeld|Mark Datysgeld]]

* GNSO Council Liaison to WG: [[Prudence Malinki]]

* ICANN org Liaison: [[Isabelle Colas-Adeshina]] (GDS), [[Sarmad Hussain]] (IDN & UA)

* GNSO Support Staff: [[Saewon Lee]], [[John Emery]] and [[Steve Chan]]

== Mandate and Scope ==

The WG’s mandate is deliberately narrow. According to the charter and EOI, the group is to examine a single issue: to identify the limited circumstances in which an ASCII gTLD and the Latin script diacritic version of that gTLD can be simultaneously delegated, and to determine the appropriate mechanism that would allow a single registry operator to operate both, under conditions that maintain security, stability, and user trust.<ref name="lsd-eoi"></ref><ref name="lsd-gnso-active"></ref>

Key elements of the scope include:

* Non-variant pairs: The PDP concerns only pairs of labels that are not variants of each other under the Latin RZ-LGR. If ASCII and diacritic labels were variants, they would already be treated under the IDN variant framework arising from the EPDP on IDNs, and no special policy would be needed.<ref name="lsd-final-ir"></ref><ref name="lsd-eoi"></ref>

* Potential visual similarity: The PDP assumes that many ASCII/diacritic pairs may be judged visually confusingly similar under the string similarity rules of the new gTLD program, which today prevent both labels from being delegated or contracted in such cases.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>

* Same-entity operation: The central question is framed around a single registry operator running both labels, analogous to the exception procedure developed in the ccTLD space for cases such as ".eu"/".ευ", while still protecting end users from confusion.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>

* Use of Latin RZ-LGR as a baseline: The WG is expected to use the Latin RZ-LGR, including the variant sets and exclusions identified by the Latin Generation Panel, as a key reference when delineating what is and is not in scope for a potential policy solution.<ref name="lsd-eoi"></ref>

The Final Issue Report and charter also anticipate that the WG will need to consider potential scoping constraints to avoid an unmanageably large set of ASCII/diacritic pairs, such as limiting eligibility to certain application types (for example, Community, Geographic, or .brand TLDs), requiring that the ASCII label be a documented workaround for the diacritic label, or limiting solutions to fully diacritic versus fully ASCII equivalents rather than including pluralization or alternative spellings.<ref name="lsd-final-ir"></ref>

While the PDP is primarily focused on the top level, its work is closely linked to the EPDP on IDNs Phases 1 and 2, which define "same entity" rules and variant management at both the top and second levels. The charter anticipates that any Latin-diacritic framework will need to be coherent with the IDN variant rules and respect the principle that variants are treated as the "same" label, while Latin diacritics are not.<ref name="lsd-final-ir"></ref><ref name="apr-ldpdp"></ref>

== Key issues and Deliberations ==

Several key themes have emerged in the WG’s deliberations:

=== Distinguishing diacritics from variants ===

Building on the Latin Generation Panel’s work, the WG revisited why code points with and without diacritics are not treated as variants in the Root Zone LGR, and how that choice interacts with community expectations in languages where the diacritic and non-diacritic forms are viewed as closely related or substitutable in everyday practice. This includes recognizing that in many languages, spelling without diacritics is viewed as an accommodation to technical constraints, not as a correct form.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>

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 40: / Line 40: @@
 The working group’s leadership is composed by:
 * Chair: [[Michael Bauland]]
 * Vice-chair: [[Mark W. Datysgeld|Mark Datysgeld]]
 * GNSO Council Liaison to WG: [[Prudence Malinki]]
+* ICANN org Liaison: [[Isabelle Colas-Adeshina]] (GDS), [[Sarmad Hussain]] (IDN & UA)
+* GNSO Support Staff: [[Saewon Lee]], [[John Emery]] and [[Steve Chan]]
+== Mandate and Scope ==
+The WG’s mandate is deliberately narrow. According to the charter and EOI, the group is to examine a single issue: to identify the limited circumstances in which an ASCII gTLD and the Latin script diacritic version of that gTLD can be simultaneously delegated, and to determine the appropriate mechanism that would allow a single registry operator to operate both, under conditions that maintain security, stability, and user trust.<ref name="lsd-eoi"></ref><ref name="lsd-gnso-active"></ref>
+Key elements of the scope include:
+* Non-variant pairs: The PDP concerns only pairs of labels that are not variants of each other under the Latin RZ-LGR. If ASCII and diacritic labels were variants, they would already be treated under the IDN variant framework arising from the EPDP on IDNs, and no special policy would be needed.<ref name="lsd-final-ir"></ref><ref name="lsd-eoi"></ref>
+* Potential visual similarity: The PDP assumes that many ASCII/diacritic pairs may be judged visually confusingly similar under the string similarity rules of the new gTLD program, which today prevent both labels from being delegated or contracted in such cases.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>
+* Same-entity operation: The central question is framed around a single registry operator running both labels, analogous to the exception procedure developed in the ccTLD space for cases such as ".eu"/".ευ", while still protecting end users from confusion.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>
+* Use of Latin RZ-LGR as a baseline: The WG is expected to use the Latin RZ-LGR, including the variant sets and exclusions identified by the Latin Generation Panel, as a key reference when delineating what is and is not in scope for a potential policy solution.<ref name="lsd-eoi"></ref>
+The Final Issue Report and charter also anticipate that the WG will need to consider potential scoping constraints to avoid an unmanageably large set of ASCII/diacritic pairs, such as limiting eligibility to certain application types (for example, Community, Geographic, or .brand TLDs), requiring that the ASCII label be a documented workaround for the diacritic label, or limiting solutions to fully diacritic versus fully ASCII equivalents rather than including pluralization or alternative spellings.<ref name="lsd-final-ir"></ref>
+While the PDP is primarily focused on the top level, its work is closely linked to the EPDP on IDNs Phases 1 and 2, which define "same entity" rules and variant management at both the top and second levels. The charter anticipates that any Latin-diacritic framework will need to be coherent with the IDN variant rules and respect the principle that variants are treated as the "same" label, while Latin diacritics are not.<ref name="lsd-final-ir"></ref><ref name="apr-ldpdp"></ref>
+== Key issues and Deliberations ==
+Several key themes have emerged in the WG’s deliberations:
+=== Distinguishing diacritics from variants ===
+Building on the Latin Generation Panel’s work, the WG revisited why code points with and without diacritics are not treated as variants in the Root Zone LGR, and how that choice interacts with community expectations in languages where the diacritic and non-diacritic forms are viewed as closely related or substitutable in everyday practice. This includes recognizing that in many languages, spelling without diacritics is viewed as an accommodation to technical constraints, not as a correct form.<ref name="lsd-prelim-ir"></ref><ref name="lsd-final-ir"></ref>
+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 ==