2025-03-26 Latin Script Diacritics - Meeting #01

PROPOSED AGENDA

1. Welcome and SOIs (3mins)

2. Updates Since ICANN82 (2mins)

3. Scope Management and Discussion (75mins)

4. Next Steps (5mins)

5. AOB (5mins)

BACKGROUND DOCUMENTS

Slides:

PARTICIPATION

Apologies: Prudence Malinki

Attendance

RECORDINGS

Audio Recording

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

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items

ACTION ITEMS:

• None

NOTES:

Welcome & SOIs

• None

Updates Since ICANN82

• Request for (voluntary) input shared with SO/AC/SG/Cs

Scope Management and Discussion

• Reviewed variants sets to help clarify what is NOT in scope for this PDP.

• Question of whether this WG’s scope of work includes things like æ, ŋ, þ, ß &c. Noted that strictly speaking, no. Reviewed Unicode table to demonstrate when code points are combinable (i.e.,, an ASCII code point and a diacritic) or not. Do not necessarily need to review the table – it can serve as an input/reference to this WG’s potential recommendations.

• Question about strict interpretation of Unicode – was it intended by the Council? Recommendation to adhere to the boundaries, established by Unicode.

Outcome: Tentative agreement to adhere to Charter and define Latin Script Diacritics per Unicode.

Outcome: Helpful also to include discussion and conclusions of what was determined to be out of scope and potentially, but perhaps as well,  how the rules can be extended (e.g., through a separate process).

• Suggestion that it might not limiting to establish a specific list of allowable characters and instead, flexibility can potentially be gained by relying on rules that strings must adhere to.

• Some questions raised about cases that that might exist outside of the Latin repertoire. Agreement to explore further how this might be accommodated, or not, given the limited scope of this PDP.

• Question raised about possibility of having ASCII/diacritic pairs being operated by separate entities. Noted that the charter envisions a single registry operator, to avoid the potential for user confusion.

• Question raised about the possibility of trying to prevent the application for the corresponding ASCII or diacritic version from a third party. Noted that the string similarity process in the New gTLD Program should prevent this outcome, with an objection mechanism also present to help mitigate the concern.

• Question about whether the string similarity panel only looks at pair-wise comparisons between codepoints, or it looks at the full gTLD. Clarified that the panel will have the pair-wise comparisons as an input to their evaluation, but will analyze the complete strings in determining whether there is string confusion or not. In other words, the panel will evaluate strings, not characters.

Next Steps:

• Work plan will be submitted to Council.

• Members are encouraged to review relevant materials (RZ-LGR for the Latin Script and relevant parts of the ccTLD Fast Track process).

• Question about a small Phase 1 process, which could potentially allow for the application of ASCII/diacritic gTLD strings, which would await completion of Phase 2 of this PDP. Performed some initial analysis that demonstrates that the timeline is too lengthy to align with the AGB. However, still evaluating whether there might be another way to add language to the AGB.

AOB

• Suggestion that as a way to narrow this PDP, may want to focus on .Brands and city names (or more generally, proper nouns), but perhaps to separate out generic strings. Noted that this is a matter for deliberations for this PDP (e.g., considering whether the criteria for allowable ASCII/diacritic pairs should be further narrowed). Some concern noted that the sequencing of the Next Round would make this sort of differentiation, by application type, difficult to implement.