Latin Script Diacritics PDP Working Group: Difference between revisions
Christiane (talk | contribs) Finished mandate section and started key section |
Christiane (talk | contribs) Added information on key themes section |
||
| 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> | 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> | |||
== References == | == References == | ||