2025-07-02 Latin Script Diacritics - Meeting #11
The call for the Latin Script Diacritics team will take place on Wednesday, 02 July 2025 at 13:15 UTC for 75 minutes.
For other places see: Event Time Announcer - Latin Script Diacritics PDP
PROPOSED AGENDA
Welcome and SOIs
Recap of ICANN83 Working Sessions
Update on AGB Inclusion of LD PDP
Review of EPDP-IDNs P2 Outputs (Worksheet [docs.google.com] to Leverage Outputs)
Next Steps
AOB
BACKGROUND DOCUMENTS
Slides:
PARTICIPATION
Apologies: Tapani Tarvainen, Asteway Negash
RECORDINGS
Zoom Recording (including audio, visual, rough transcript and chat)
GNSO transcripts are located on the GNSO Calendar
Notes/ Action Items
[OUTCOMES]
Filled in Spreadsheet [docs.google.com]of relevant recommendations and wrote the consensus in the decision tab
[ACTION ITEMS]
Prepare some examples for P2 same entity principle at the second-level to discuss next meeting
[NOTES] Meeting #11 Slides [icann-community.atlassian.net]
Welcome and SOIs
Michael welcomed Board liaison Alan Barrett
Recap of ICANN83 Working Sessions
Discussion of if there were any questions
Update on AGB Inclusion in LD PDP
Introduced the issues with the AGB and clarified that this cannot be used in the current AGB, but can utilize the SPIRT process for inclusion after AGB adoption
Suggested speeding through the LD PDP or a developing small team to draft recommendations
Clarification
EPDP-IDNs P2 looks at the second level variant management
a. Filled in worksheet [docs.google.com]
Phase 2 Outputs
Final Rec 1: agreement of same entity principle for second-level gTLDs
Broad discussion of second-level as to whether diacritics should be treated in the same way. The goal is to prevent user confusion because of the second level depending on the registry.
At TLD level there is a limited number of applicants. 2nd level is free for all, and variant like at the second level, there will be problems and way too complicated across all languages
Suggestions we need to clearly disambiguate between variants and diacritics (ie., pseudo-variants)
Sarmad: three different scenarios 1) variants at top level and second level. That is solved by IDN-EPDP and SubPro and that applies 2) we don’t have variants at the top level but strings grouped together because of diacritics and same strings and variants under them, we want to discuss how to define the policy for this to remain open. That is a relevant discussion to have. 3) Diacritized version at top level not variants and diacritized at the second level which are not variants, unlikely we want to go there.
AI: come up with visual examples for next meeting to discuss
Clarification: currently TLDs .quebec are enforcing the block or allocation to same registrant at the second-level. Reason is to prevent confusion. We cannot dictate general policy, but dealing with a specific exception for something confusing for the end user. General rule that registries decide variants, but we are not necessarily bound by this special case and it could be a special rule
For recommendations from our group we either recommend everything is a bundle or not.
Example from Sarmad:
1) Variant.variant
variant.LDalternate <——
LDalternate.LDalternate
o 1) already decided
o 2) TLD and LDalternate what should happen with variants? This should also adhere to same entity principle because we take the ASCII and LDalternate as kind of the same pseudo variant and should be Same entity
o 3) What do we do with LDalternate.LDalternate should those also adhere to the same entity principle? Something registry is free to decide via policies? Do we suggest this?
Continued to fill out the worksheet [docs.google.com]
Recommendation 3: Applicable for LD PDP, nothing to apply retroactively for exempted cases
Recommendation 4: Sarmad if the LD alternate at the top-level to potentially behave in a similar way to variants at the top-level, then these second level for how these could be extended as well
Recommendation 5: Sarmad: 2nd level IDN tables developed by registries, they can always add more variants. That option is not excluded. This recommendation says whatever the TLD registry decides, if they have multiple IDN tables, they must be harmonized based on whatever IDN table is being used. This recommendation still holds, but is not really relevant here as it is already approved and has no implications for our work
Recommendation 6: Determined to be already covered by IDN EPDP and no additional work needed as we won’t change any variant rules here.