2025-05-21 Latin Script Diacritics - Meeting #08

PROPOSED AGENDA

1. Welcome and SOIs

2. Recap of Meeting #7

   1. Outcome and Action Items

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

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

4. Next Steps

5. AOB

BACKGROUND DOCUMENTS

https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU-kQGF_c/edit?usp=sharing

PARTICIPATION

Attendance

Apologies: Sebastien Ducos, Asteway Negash, Juliana Harsianti, Prudence Malinki, Satish Babu

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. WG members to take some time read 4.4 for the beginning of next call from the spreadsheet[docs.google.com]

2. WG members to read Challenge Mechanism for String Similarity Review (Draft AGB Text)

3. 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 worksheet next week

[NOTES] Meeting 8 Slides [icann-community.atlassian.net]

1. Welcome and SOIs

2. Recap of Meeting 7

2. Outcomes and Action Items

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

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

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

• Reminder that discussion of fees will be deferred until later in the process

• Began filling in at 3.14

• 3.18 discussion of Reserved Names which is now known as “Blocked Names”, it is a finite list and not applicable. 

• 3.20 N/A discussion that this is not an issue as long as the applied for string is not a variant of blocked name. If base ASCII is already reserved. Key is that we do not provide any specific advice to override it

• 3.21 (Determined prior and not applicable as it already applies) discussion of possible cross between this and current work based on accented versions in latin script. Do we just leave as is? Would we need any special treatment in these cases? It would apply in these cases as well as long as it meets the eligibility through other recommendations. If this case comes under recommendations of this PDP then those apply here as well

• 3.22 (Determined prior and not applicable as it already applies) discussion that mandatory string requirements must apply. Wherever it says respect IDNA rules we should keep by default unless there is an overwhelming reason for us not to do that

• Question: we know that the RZ-LGR is an authoritative source for possible strings. Do we have in mind a list of possible diacritic versions of Latin strings that would be available for application? A: we have list based on character basis https://github.com/mark-wd/ASCII-Unicode-Diacritics-Analyzer-Tool/ [github.com] . This is the finite list of what is possible to apply for. That would also have to meet the mandatory string requirements for eligibility.

• Since this is not authoritative, this is still just a guide so people can look at characters that would fall into PDP rules. For authoritative definition it would be the Unicode table. 

• Will there be a way that people can insert something to find out whether it is eligible or not? An authoritative guide for applicants in the future. 3.22 has to apply because you cannot go outside of that.

• The tool is helpful if we are in full agreement with Unicode, there might be cases in which that is specific to DNS and root zone, underlying question, are we in full agreement with Unicode? If we are then the list is sufficient

• 3.22 if we don’t say anything, are the general rules still applicable? Or does it make sense to clearly state that we are not changing it. Staff concurs that it is an overlap ASCII and diacritic are applied for gTLD string and would be applicable without stating it explicitly

• 3.23 (Determined prior and not applicable as it already applies)

• 3.24 Seems sensible to not relitigate. Where the label becomes potentially ineligible due to string similarity. Some of these are not related to the step in that process. RZ-LGR is more fundamental check than string similarity. 

• 3.24 (Determined prior and not applicable as it already applies)

String Similarity Review

• 4.1 Discussion this could open to a range of are we making the two with diacritics confusingly similar or do we need another set of criteria? This needs to be discussed once we finish with this section of looking at EPDP-IDNs rules

• Initial reaction would be that this should apply to any applied-for string. After String Sim applies there might be certain other things we can do. If this causes a situation that it is listed as similar and therefore blocked. Then maybe yes we should say something about it. Principles don’t change, but we might have something to say that this PDP creates an exception, there could be remedies applied to it

• This feeds into the process that creates the reasons for this PDP, more of an input to the PDP rather than the PDP trying to do. SSR and RZ-LGR gives us text to work with but don’t want to change as such

• This describes the process of SSR, not what happens as an outcome. This is only a description of the process and will not do any recommendations to change it

• 4.2 SSR is a given fact, and we work with the results but will not change it

• 4.4 Take some time read 4.4 for the beginning of next call

• 4.4 if this string compares with different categories, then it can result in different actions. Wouldn’t it be items that need exceptions for this PDP? Perhaps this is where the PDP might need to look in detail for this? At some point we have to make our rules, and this might be the place for it. Should we create a new section for this or if this is the right place to make those rules?

• These rules are the ones that feed into the current PDP then the current PDP says given these rules and outcome then how to deal with particular subset of outcome. These rules would apply, and the current PDP would be more how to deal with output of these rules and not to change the rules themselves

• Be careful to not change the base rules, perhaps those that we have discussed to accept the base rule, but create exceptions for this PDP, indicate somehow that when we do create the exception to see if it applies effectively to those that we are marking. 

Objection Process

• 5.1 may have our own objection process, but that would be later in the process as SSR would be out of scope. If it is rejected due to SSR and it is a diacritic then we would make new rules

• Principle should apply but we are not dealing with variant labels. Are existing objection processes enough to deal with everything already?

• Discussion not of SSR, it is the visually confusingly similar process. Perhaps look to the string confusion objection scope to see if that covers it. 

4. Next Steps

• WG to review the existing body of work related to CQ 3 (EPDP-IDNs P1 [gnso.icann.org]-2[gnso.icann.org])

• Can we clarify the question from Bill that String similarity and confusing similarity are same OR different? To be discussed next week!

5. AOB