2025-05-14 Latin Script Diacritics - Meeting #07

2025-05-14 Latin Script Diacritics - Meeting #07

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

For other places see: https://tinyurl.com/4azdk49w

PROPOSED AGENDA


  1. Welcome and SOIs

  2. Recap of Meeting #5

  • Outcome and Action Items

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

  1. Next Steps

  2. AOB

BACKGROUND DOCUMENTS


Slides

Spreedsheet



PARTICIPATION


Apologies: Tapani Tarvainen

Attendance



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. Leadership/Staff discussed if EPDP-IDNs P1 Final Rec. 7.1 needed to clear with ICANN legal and determined that it is not needed at this time in this PDP given the broad recommendations

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

 

[ACTION ITEMS]

  1. WG to review the existing body of work related to CQ 3 (EPDP-IDNs P1 [gnso.icann.org]-2 [gnso.icann.org]) to continue filling out the spreadsheet next week

 

[NOTES]

  1. Welcome and SOIs

  2. Recap of Meeting 5

a.                  Outcomes and Action Items

  • Completed review of Early Input responses; Summary can be found on wiki here [icann-community.atlassian.net]

  • Agreement to use the relevant adopted SubPro and EPDP-IDNs Outputs as a foundation to build the LD PDP Outputs on; focus to be on EPDP-IDNs

    • Leadership/Staff discussed if EPDP-IDNs P1 Final Rec. 7.1 needed to clear with ICANN legal and determined that it is not needed at this time in this PDP given the broad recommendations

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

a.                  Continue with Review of EPDP IDNs Outputs (Worksheet [docs.google.com] to Leverage Outputs)

  • Discussed worksheet items 3.1-3.6

  • Agreement that 3.1 is NOT relevant for our purposes. 

  • Sarmad suggests to consider our cases to consider these similar to variants and thereby transfer some of the recommendations but with the difference that we do not have any disposition values here because there is no real variant relationship

  • Sarmad asks if we are drawing a parallel to talk about the relationship between two strings at the top level and second level. Are we mapping the same kind of variants to similar strings

  • 3.1 consensus not necessary for our case to have such a rule for LD PDP

  • 3.2 consensus that it would apply and an application would have to come in an official round of applications 

  • There is no other solution, like a special application round, it would fail. It is not needed nor realistic

  • 3.2 the principle is applicable that a new application is necessary for existing gTLDs

  • 3.3 similar to apply in the immediate next round when this policy applies it can apply for the diacritic version, but it does not have to. Any future round. 

  • 3.3 is applicable 

  • 3.4 was agreed to be determined later, but led to a robust discussion about if you apply for a TLD and one of its variants is it separate applications or a single application? 

  • Primary and variant are distinct strings. At the time of application it is not something that is known whether they are similar or distinct to each other. If they are not found similar, they could be distinct strings as a single application

  • Important Question: How to deal with the whole process? This is probably at the crux of the issue. At least it may not apply directly, the question is there is a possibility that they are not similar by string review and would proceed as two applications. If we specifically create a different mechanism this group will need to decide. For mapping it does not apply. Longer discussion needed to handle the application process itself

  • There was a discussion of fees that would be deferred to later on in the process 

  • 3.25 TBD at a later date

  • 3.5 Sarmad gave background for SSAC advice that led to this recommendation 

  • 3.5 first needs to specify the rules before we say something about how people apply for them. This depends on the fact of what we put into our rules how those are run

  • 3.6 is based on 3.5 so it makes sense to also postpone that

  • 3.10 general consideration, but the open question about our fees. Cost recovery principle it should apply, what is calculated in the cost. There could be evaluation processes not applicable for diacritics. Cost recovery principle should stay the same for every application

  • 3.11 What do we do with our diacritics? Price, if those are separate evaluations, you cannot in practical terms not submit the fee. Amadeu in favor of different TLD applications if it fails, then it could be separated. In favor of having a reduced fee for a second one, there is some work there, but 2 for 1 or 3 for one does not reflect the costs

  • Postpone price discussions. Does not change any further decisions. That can be decided at the end. Depending on whether we want to have one or multiple applications this is dependent on the price question

  • Obviously the cost for one application cannot be the cost for 1 application plus four variants. Cost is distributed over general application fees

  1. Next Steps

 






Related content