/
2025-07-02 Latin Script Diacritics - Meeting #11

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

  1. Welcome and SOIs

  2. Recap of ICANN83 Working Sessions

  3. Update on AGB Inclusion of LD PDP

  4. Charter Question 3 [gnso.icann.org]

  1. Next Steps

  2. AOB

BACKGROUND DOCUMENTS

Slides:

 

PARTICIPATION

Apologies: Tapani Tarvainen, Asteway Negash

 

RECORDINGS

Audio Recording

Zoom Recording (including audio, visual, rough transcript and chat)

GNSO transcripts are located on the GNSO Calendar

 

 

Notes/ Action Items

 

[OUTCOMES]

  1. Filled in Spreadsheet [docs.google.com]of relevant recommendations and wrote the consensus in the decision tab

[ACTION ITEMS]

  1. Prepare some examples for P2 same entity principle at the second-level to discuss next meeting

 

[NOTES] Meeting #11 Slides [icann-community.atlassian.net]

  1. Welcome and SOIs

  • Michael welcomed Board liaison Alan Barrett

  1. Recap of ICANN83 Working Sessions

  • Discussion of if there were any questions 

  1. 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

  1. Charter Question 3 

  • 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

  1. variant.LDalternate    <——

  1. 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.