/
2025-07-16 Latin Script Diacritics - Meeting #13

2025-07-16 Latin Script Diacritics - Meeting #13

The call for the Latin Script Diacritics team will take place on Wednesday, 16 July 2025 at 13:15 UTC for 75 minutes.

For other places see: https://tinyurl.com/yu9hycsh

PROPOSED AGENDA

  1. Welcome and SOIs

  2. Recap of Meeting #12

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

  1. Next Steps

  2. AOB

BACKGROUND DOCUMENTS

Slides:

 

PARTICIPATION

Attendance:

Apologies: Justine Chew

 

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]

  • Staff to make a note on slide 7 for yilmaz dot less i example

  • No meeting next week 23 July due to leadership absence, calls to resume 30 July

  • All to review TBD items in spreadsheet [docs.google.com]

 

[NOTES]

  1. Welcome and SOIs

  2. Recap of Meeting #12

  • Reviewed agreement on SLD cases 

  • Case 1.2-1 variants at the second level with IDNs

  • Yilmaz example with dot less i to be updated

  • Query about second level for ASCII and second level there is no single entity principle as that is up to the registry.

  • Strongly encourage registries to apply this perhaps in the language without making it a rule

  • Sarmad: in this context there is already another document for IDN implementation guidelines. Section 2.5 talks about confusability of labels. Generic recommendation from Seb may already be there; it can be done in the context of the guidelines from here.

  1. Charter Question 3 

  1. EPDP-IDNs P2 looks at the second level variant management

i.Filled in worksheet [docs.google.com]

  • Continued on implementation guidance 12 on Uniform Rapid Suspension System. For variants the same entity does not apply to all of them. Complainant must submit every domain they would like suspended

  • Diacritics are a much larger variant set than IDNs, if there is another top-level linked to another diacritic, at the second level variants are solved by IDNs. Only the same entity principle is only at the top-level. 

  • Recommendation 13: if same entity applies to new strings work then the dispute resolution providers should be apprised of these as well. 

  • Suggestion to use Mark’s R-tool since it is internal that it might be helpful like an IDN table. We don’t actually need to know what diacritics exist as the same entity is only at the top level, the second level is out of scope. IANA database would show if there is a diacritic TLD of that

  • If this is not enforced by the registry for any top level domain. There is a solution for top-level domain, but not for second level

  • Recommendation 14 EPP extension is currently being worked on for IDNs. Suggestion to align with that.

  • Sarmad: question about a similarity relationship vs. a variant relationship and is that easily portable to this scenario? Michael: it is currently still in development perhaps calling it connected, but aligning will make life easier

  • Sarmad: could be an implementation guidance to 

  • Implementation guidance 15: general agreement, Sarmad clarified if this is related to EPP or RDS. Can’t be EPP and this is other entities and end-users not language between registries and registrars

  • Final Recommendation 16: Yes to IANA transparency

  • Implementation Guidance 17: also valid for our cases with a tweak of wording since it is not about variants, but diacritics

  • Final Recommendation 18-21 all IDN implementation guideline related

  • Sarmad: IDN guidelines are for gTLDs and ccTLDs and developed by group from both groups. The work is largely focused on second level implementation of IDNs, in that sense, unless we want to talk about 2nd level IDN implementation work, otherwise this will not be relevant

  • Diacritics at second level are not really regulated, it is something that could be included in IDN implementation guidelines as these problems already exist now with single TLDs 

  • Review of TBD Items

  • PDP is about creating an exception process for one specific problem. If you apply for two TLDs where those are diacritics and not variants, you can apply for each TLD, but there is a high chance that one will be rejected because it is too similar. We want to avoid this rejection and make it possible for entities to apply for both TLDs. We are not trying to make any further rules that make this easier or to encourage people to do this if the rejection would not take place. Solve problem of rejection, but not making it easier than that

  • First discussions to note that we have voluntarily limited ourselves to the notion of what a diacritic is. But other groups may study those separately with the same sort of method when applied to them. By not making rules about them, not saying it should not be dealt with at all, but it is sensible to deal with in the future. It is out of scope

  • 3.4: One application for all TLDs or separate applications: Variants, it was combined in a single application. Single application suggested. 

  • Wording easier to be bundled in same entity, but can be problematic at string similarity review

  • Suggested: have a single application and by that already states that those TLDs will be run with the rules of the PDP, string sim check would not be necessary, it would make this known to the applicant. Idea is to write with the application if you want to use the PDP rules or not

  • Steve clarified thinking about the question makes sense to signal up front that they want to question that applicants for ASCII and LD are making a planned decision. Applicant for ASCII and LD are not waiting for a string sim review to decide to operate it in that fashion. 

  1. Next Steps

  • No meeting next week 23 July due to leadership absence

  1. AOB