- Gnso-latin-diacritics - lists.icann.org

Proposed Agenda for Meeting #32
by Saewon Lee April 21, 2026

April 21, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #32 on Wednesday, 22 April 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #31 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to confirm language for IG8, review comments for PR7, PRs 12-13, PRs 18-19 (Rec #s according to the current Public Comment Review Tool, prior to updates), as well as PRs 2-3, and IG11 and PR50. Please review the updated proposed language resulting from Meeting #31 in pp.5-6 and p.30 for IG8 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVe…> As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> We appreciate your kind review of both materials each week. Much appreciated, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Post Call | Latin Script Diacritics PDP | Wednesday, 15 April 2026
by Devan Reed April 15, 2026

April 15, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 15 April 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/fQBANw> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. Kind regards, Devan Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes Meeting #31
by John Emery April 15, 2026

April 15, 2026

Dear LD PDP WG, Please see attached below the outcomes, action items, and notes from Meeting #31 on 15 April 2026. [OUTCOMES] * [ACTION ITEMS] * Staff and Leadership to update IG 8.6 to include “negative” will involved the dissolution of the set * WG to think through the meaning of conservatism and to brainstorm potential ways to increase conservatism to address ICANN org’s comment. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #29 a. Key Outcomes and Action Items * Went through the slides<https://icann-community.atlassian.net/wiki/x/fQBANw> to discuss updated language from the previous meeting. * Confirmed language of PR6 and its division into IG7 * IG 7 and IG 8 adjustments outlined based on last week’s discussions in the slides<https://icann-community.atlassian.net/wiki/x/fQBANw> * Discussion for IG 8 of possible scenarios the timing with the evaluation would not be dealt with in our PDP. * Ariel explained the process of evaluation timing will occur in stages for string evaluation. At the end, there will be an outcome report with some processes kicking in. The WG should not be too specific as this is community policy from SubPro PDP. * 8.6 causes dissolution of the set for the evaluation of an outcome of an ASCII by causing the dissolution of the set. 3. Review of LD PDP Initial Report Public Comment * Took holistic view of ICANN org comment though slides<https://icann-community.atlassian.net/wiki/x/fQBANw> for comments received for PR 1. Explanation of substantive vs. non-substantive public comment * ICANN org substantive comment for PR 1 overview given with consideration for what additional security and stability issues may arise from the introduction of these sets. Conservatism principle is primary across all recommendations and if there are additional measures needed to prevent proliferation of exceptions * A number of substantive comments outlined on PR 1 about scope * Read through adjustments to PR 7, PR 12-13, PR 18-19 in relation to PR 1 from ICANN org * New suggestion by Claude based on the inclusion principle and conservatism principle outline on slide<https://icann-community.atlassian.net/wiki/x/fQBANw> 20. Exclusion was when a glyph was not related to an ASCII letter, the glyph is automatically excluded from the set * Discussion of comment on PR 1 from ICANN org looking at scope for what characters are reasonably supposed to be in the scope of this project. This is an RZERC question that this group is not equipped to answer * Sarmad: added context to the comment from ICANN org. This PDP will eventually allow for some strings to go into the root zone. ASCII and diacritic into the RZ this process for the applicant would pull those strings into a single application and set could still go into the RZ. Another case with 3 strings through an exceptions process would not have made it to the RZ. Normal policy any strings similar do not go into the root zone. Variants are well-defined and allowed, this is extending the process for non-variant strings that can go to the root zone. * Sarmad summarized that variants is a well-defined process and predictable through the RZ-LGR. These sets are defined by the applicant, which defines the root zone. It is an exception process allowing some strings to go into the RZ-LGR which would not have made it through the regular process. * Discussion based on the comment with a belief that the WG is conservative and the scope of the characters should be the element addressed. * Sarmad: This PDP is an exception process to allow for some TLDs to move forward. Through this process any ASCII character all the discretized versions are getting an allocatable disposition and this is different than the RZ-LGR was designed. What is presented from a character level disposition. At the string level you can go into the root zone. Theoretically more strings at the character level and at the string level would introduce more into the root zone, this is a less conservative solution for the root zone. * Query about RZ-LGR e and e acute or any other LD are not defined as blocked variants? They are simply not variants? There are a few diacritics that are variants. These are out of our scope. The RZ-LGR allow all the characters to be used in TLDs, it is whether we are allowing similar TLDs to be operated by the same registry. * Michael outlined two opposing opinions. WG and ICANN org to find a compromise that works. To be able to uphold the conservatism principle 1) restrict characters (group is mostly opposed to that along with other commenters) this is not a good way to achieve this and don’t want to give preference to language group. 2) That would allow the set of diacritics or second option from Tapani and that would be to change some of the recommendation that will make them more conservative. * Sarmad: Similar strings would be allowed in the RZ to exist together. Conservatism would ask to reduce it or make it smaller. There are other ways to eventually reduce the strings in the policy. This is not an isolated request or suggestion. In the variant discussions and policy. RZ-LGR by design minimizes allocatable variants. * Sarmad clarified with example of through the regular policy process two strings considered similar both strings cannot proceed to the RZ, only one can proceed after contention resolution. If those strings through this process to allow both to go the RZ. * The exception for the number of possibilities is getting too big. Sarmad is saying this is aligned with the charter and the PDP. The org comment is asking if this can be done more conservatively. * Raising the issue for SSR of the Internet, but the question is a dilemma of what is the definition of conservatism today, and how would that change over the future. All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0

Proposed Agenda for Meeting #31
by Saewon Lee April 14, 2026

April 14, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #31 on Wednesday, 15 April 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #30 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to confirm language for IG7, IG8, review all comments for PR1 to help continue and conclude discussions for the work scope. Please review the updated proposed language in pp.2-6 and p.29 for IG7 and IG8 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> Please also refer to all the comments received for PR1. We appreciate your kind review of both materials each week. Much appreciated, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Post Call | Latin Script Diacritics PDP | Wednesday, 08 April 2026
by Julie Bisland April 8, 2026

April 8, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 08 April 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQBENw> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

Re: Diacritics definition
by Tapani Tarvainen April 8, 2026

April 8, 2026

Following up today's discussion: * There is no universally accepted definition of diacritics we could use, in Unicode or elsewhere. (The original, linguistic definition is language-specific and thus useless for DNS.) Therefore we are forced to define it for ourselves. * The anonymous Unicode expert's argument that "LATIN WITH..." might include letters that aren't diacritic is, in this context, circular: if we include them in our defintion then they are diacritics by (our) definition! We should choose a definition that works for us. Well-defined, mechanically testable, predictable, easy to implement &c. What doesn't matter is whether or not all characters there are diacritics by some other definition, as long as they don't cause any problems for our purposes. -- Tapani Tarvainen

2 1

Proposed Agenda for Meeting #30
by Saewon Lee April 7, 2026

April 7, 2026

Dear LD PDP WG, I hope those of you who celebrate Easter had a great Easter holiday weekend! Please find below the proposed agenda for LD PDP WG Meeting #30 on Wednesday, 8 April 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #29 * Key Outcomes and Action Items 1. Review of LD PDP Initial Report Public Comment 2. Next Steps 3. AOB This week, the WG is expected to confirm language for PR6 (and now a new IG7), IG8, and conclude the scope of work discussion, prior to moving on with IG11 and PR50. Please review the updated proposed language in pp.2-5 and pp.22-23 for PR6 (and IG7) and IG8 here prior to the meeting: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-… As an ongoing process during the review of Public Comment submissions, the WG discussions are updated in the Public Comment Review Tool here for your review: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> We would appreciate your kind review of both materials each week. Much appreciated, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Post Call | Latin Script Diacritics PDP | Wednesday, 01 April 2026
by Terri Agnew April 1, 2026

April 1, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 01 April 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/QgBANw> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. Kind regards, Terri Policy Team Supporting the GNSO

1 0

Outcomes, Action Items, and Notes Meeting #29
by John Emery April 1, 2026

April 1, 2026

Dear LD PDP WG Members, Please find attached the outcomes, action items, and notes from the 1 April 2026 Meeting #29 [OUTCOMES] * [ACTION ITEMS] * Staff to add language for PR 6: “This can be divided into one of the following scenarios” * Leadership and staff to look at if one already has the ASCII TLD and applies for several LD TLD versions of it, what happens? The process of adding TLDs to existing ones, needs to be a bit more explicit about this particular case either with a new recommendation or with additions to PR 6 [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #28 a. Key Outcomes and Action Items * Went through slides<https://icann-community.atlassian.net/wiki/x/QgBANw> reviewing what happened at Meeting #28 through the public comment review tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…>. * PR 6 and IG 8 there needs to be two scenarios for PR 6 with examples given in the slides<https://icann-community.atlassian.net/wiki/x/QgBANw>. * Both PR 6 and IG 8 are in the application round, other topics like PR15-28 are in the allocation process and PR 29-38 are in the delegation process. Today’s discussion is only on the Application Process. * PR 6 rationale explanation for removal of LD or ASCII gTLD in application discussed on slides<https://icann-community.atlassian.net/wiki/x/QgBANw> 9-10 discussion of exceptions process and inability to switch between standard and exceptions process. But it is not a problem to drop all but 1 TLD; it is not unbundling, but would dissolve the set. * Question about if one already has the ASCII TLD and applies for several LD TLD versions of it, what happens? The process of adding TLDs to existing ones, needs to be a bit more explicit about this particular case. It should be okay, but should there be some explicit wording for this? * Utilized Sarmad’s suggestion for the two cases in PR6 and outlined new language on slide 12 * Suggestion to add additional language on the particular case of one already having an ASCII and applies for several LD TLDs. * Sarmad: in the case where there is an existing gTLD and more are being added in an application round and through that application round some could be dropped. He was wondering whether there would be a bit more restrictive recommendation where the existing gTLD could not be dropped. That is slightly different from scenarios 6.1 and 6.2. Existing one should not be able to be dropped, because that is out of scope as an existing TLD * IG 8 outlined on slide 13 discussed and possibilities discussed on slides<https://icann-community.atlassian.net/wiki/x/QgBANw> 15-16. * Query on scenario 5 if the ASCII fails could the LD TLDs proceed? This is not possible as lanes could not be switched. If you want to start with the LD PDP exceptions process, you are not allowed to unbundle and switch to two or more unbundled TLDs. * SCOPE OF WORK discussion * List discussion between Mark and Tapani for Character choices vs. character limits on slides<https://icann-community.atlassian.net/wiki/x/QgBANw> 17-21 * The charter just says that WG has to deal with diacritics and the WG discussion had decided early to make the rule of de-composible unicode, but that could be expanded within the scope of the charter it can be included. * Cannot make changes to RZ-LGR from Council guidance, then there would have to be an artificial form on top of RZ-LGR, that would be a new creation that unicode or ICANN org does not have. To make the policy happen is one thing, when a database is handling a user then it must understand the TLD as a variant. Ideally the implementation should be something tangible that is easy to implement beyond the DNS level. * “Small Latin letter with” appears to be a novel solution to expanding from unicode decomposed diacritics only. Is this a good fix that addresses the revisions asked to do? * Summary: currently considering those diacritics decomposable or decomposed already. Tapani argues that while these are all diacritic characters there are more that are called “SMALL LATIN LETTER WITH” although they are not decomposable then they are still technically easy to implement, it would need some additional rules. Two things to consider, LATIN SMALL LETTER WITH would still leave out letters with two or more diacritics. * All the cases with two diacritics would be included if you use both decomposable AND Latin SMALL LETTER WITH. This would cover more diacritics that would be an easy solution that is technically feasible * Third possibility to add letters that are not real diacritics such as ae combined, then that would be out of scope as it is restricted in the charter and would be a separate PDP All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0

Diacritics definition
by Tapani Tarvainen April 1, 2026

April 1, 2026

Dear all, Looking at the initial report recommendation 1, it gives the chosen definition of diacritics as a fact, without explaining or justifying it in any way. It should, so that if someone wonders why ø or ŋ are treated differently they should be able to look at the report and find an eplanation. I also note the ISOC Norway comment that wants a technical reason for the exclusion of characters used in Norwegian and Sami. I tried to think of how to explain it. As I recall, the argument was that the charter specifies diacritics only and Unicode defines them that way and if we want to include something else we'd have to go back to the council and there's no time for that. But does Unicode really define them that way? I went to the source to see what Unicode actually says about the matter, and importantly also what it does *not* say. Not an easy task - there's *a lot* of stuff in there. But try as I might, I could not find a general definition of "diacritic" anywhere. Perhaps I've missed it - if so, feel free to point it out. There's lots of talk about combining diacritic marks and decomposable diacritics - but no claim that those are the only kind of diacritics. It's simply that for Unicode's purposes the non-decomposable diacritics don't need any special treatment, so there's no need to even define them. For Unicode, decomposable diacritics are special because they need special rules for canonicalization. But for our purposes that doesn't matter. In effect we took the Unicode table of decomposable diacritics and decided to treat it as if those were the only diacritics. This decision was not given to us by the charter nor by Unicode, it was our choice. I see no good reason not to allow all Unicode characters described in Latin-1 Supplement or any of the Latin Extended tables as "LATIN SMALL LETTER <x> WITH <y>" where <x> is an ASCII letter and <y> is any glyph that modifies the base letter (which is the general meaning of "diacritic mark") in a way that makes them confusable, regardless of the existence of a decomposed canonical equivalent, as long as they are in the RZ-LGR. My favorite example here is of course "latin small letter with stroke", ø. If we conclude that there is a good reason for excluding such non-decomposable diacritical characters, we should spell it out. I don't see any good *technical* reason to exclude even characters like ð, þ, ŋ, æ etc, but they are not diacritical and thus outside of the charter, and in some cases might require aditional considerations, so I guess we'd have to back to the council for those, or wait for another PDP ("Extended Latin Characters PDP" perhaps?). (Side note: during a coffee break discussion in Mumbai someone said old issues shouldn't be relitigated *unless* there're new facts or new viewpoints to consider. Here I think there are.) -- Tapani Tarvainen

8 23