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

Post Call | Latin Script Diacritics PDP | Wednesday, 01 July 2026
by Devan Reed July 1, 2026

July 1, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 01 July 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AYA8PQ> (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 from Meeting #38
by John Emery July 1, 2026

July 1, 2026

Dear LD PDP WG Members, Congratulations on finishing the Public Comment and deliberations! While the meetings have ended the homework is coming down the pipeline for all of you for review and finalization of policy language later in July. Please be sure to review the next steps on the calendar from the slides for a full picture of next steps: https://icann-community.atlassian.net/wiki/x/AQAwR [OUTCOMES] * Agreement of the WG for the updated text of PR39 and PR40 * WG Agreement to update language of PR48 aligned with ICANN org Public Comment on “allocated” * Agreement to update PR6 and IG7 * WG Agreement to add PR30 [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * LT and Staff to update Rec X rationale as highlighted by Sarmad also to discuss possible IG for edge case examined in the call. [NOTES] 1. Welcome and SOI Updates 2. Recap of LD PDP Meeting #37 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ> and agreement to discard PR18 and PR19, a path forward for PR14, and HRIA * PR39 and IG40 were discussed to attempt to cover all cases in the recommendations and a solution was proposed in slide<https://icann-community.atlassian.net/wiki/x/AYA8PQ> 6. * PR39 updated language presented to the WG. IG40 Updated to PR40 to supplement PR39. To summarize all diacritics that are defined in PR1 allowed at the top level. Those should also be included in the set at the 2nd level for consistency between the two. This ensures the same entity requirements. The registry is free to change the disposition value, if the user base uses diacritics interchangeably, they can change blocked into allocatable variants, and can add some at the second level. Registries could make a variant of ae and æ at the second level they could do that even though it is not in our set or drop other characters from the set. * PR39 the use of “variant” as a term could be confusing. They are variants as determined by the second-level LGRs and those are given in PR40 so the two are linked. PR 40 defines those variant relationships and 39.3 defines those by PR40. * Recommendation X language clarified with additional text. * Sarmad suggested in the last sentence that once the conflict is resolved an applicant can proceed and apply for additional LD TLDs. Could be added in the rationale more clearly. Edge cases discussed for transferred gTLDs * Exemption for Rec X to be discussed by LT and Staff 3. Review of LD PDP Initial Report Public Comment * PR48 updated agreement and Public Comments examined in the slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ> to address concerns and this was discussed in-depth. Idea that it should be changed to only allocated. WG Agreement to change language for PR48 “all allocated domain names from the ASCII/LD domain set” * IPC comment on PR48 on fees had agreement to not be addressed * IG52, PR53, IG54 outlined in the slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ>. Request from ALAC has a good intention, the comment was acknowledged and received. It is a sensible request, but the recommendations we currently have are sufficient as is. * IPC requested IG52 to be discarded. Michael noted that there appears to be a misunderstanding of the recommendation in their PC as it does the opposite of what they are suggesting. WG determined that IG52 is needed * Agreement for glossary changes based on Public Comment * EPDP IDNs Phase 1 Rec 5.5 was deemed not applicable and ICANN org suggested that perhaps it is applicable as outlined on slide<https://icann-community.atlassian.net/wiki/x/AYA8PQ> 17 with a request to consider objection outcomes. Proposal was to update PR6 and IG7 to account for this. * Agreement from WG to update PR6 and IG7 as outlined * ICANN org EPDP-IDNs P1 8.2 and 8.3 discussed on slide<https://icann-community.atlassian.net/wiki/x/AYA8PQ> 19. Proposal to propose a new recommendation PR30. * Enthusiastic agreement for non-binding guidelines 4. Review of Proposed Table of Contents for Final Report * Reviewed slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ> regarding Table of contents 5. Consensus Call Process Reminder * Reviewed slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ> on how the consensus call process works with consensus designations and full consensus/consensus discussed 6. Next Steps * Reviewed slides<https://icann-community.atlassian.net/wiki/x/AYA8PQ> for the timelines and consensus call 7. AOB 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 #39
by Saewon Lee June 30, 2026

June 30, 2026

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #39 on Wednesday, 1 July 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of Meeting #38 · Key Outcomes and Action Items 3. Review of LD PDP Initial Report Public Comment 4. Review of Proposed Table of Contents for Final Report 5. Consensus Call Process Reminder 6. Next Steps 7. AOB This week, the WG is expected to finalize discussions for all necessary items related to the public comments received. Please review the Public Comment submissions in their entirety through the Public Comment Review Tool here: https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1…> If time permits, we will also go through items 4 and 5 related to the conclusion of this work as the WG prepares for the Consensus Call and Final Report. Looking forward to seeing you all tomorrow! Best regards, 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, 24 June 2026
by Devan Reed June 24, 2026

June 24, 2026

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 24 June 2026 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQAwR> (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 #38
by John Emery June 24, 2026

June 24, 2026

Hello LD PDP WG Members, Please find the attached outcomes, action items, and notes from Meeting #38 on 24 June 2026. [OUTCOMES] * No objections from the WG to discard Recommendation 18 and 19 * PR14 agreement on path forward. [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * Leadership and Staff to discuss IG40 with Sarmad to revise based on discussion. * Leadership and Staff to return to Rec X based on discussion. [NOTES] 1. Welcome and SOI Updates 2. Recap of LD PDP Working Session at ICANN86 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> and shared updated wording for PR39. How is 39.3 implementable? This would be solved by IG40 would be new that 39.3 would be allocatable variants. LGR should be developed for a second level. * IG40 discussed, the idea to broaden this is that not every registry operator has to create a second-level LGR, rather to have ICANN develop one to have more consistency there. * Sarmad commented ICANN can be directed to do this. Had a question about designing reference LGRs. It would be closely worked with the script community to design them. The definition of variants and which is allocatable vs. blocked. Making them all allocatable would be another layer. Why all could/should be variants if there is a possibility to consult with the community in the process would improve the process. A practical solution would be for script experts to debate amongst the parameters. Should be a discussion on what should/could be allocatable. * Meaning of this for the diacritic variants may not be undefined as not being variants. Good suggestion to include the script communities. * IG40 discussed in-depth and the purpose here is to establish protection for user-confusion for variants. Does this work actually need to be done. All variants here should in principle should be allocatable unless there is a strong reason for doing so. * The reduced character set is meant with the second part allowing for adaptation to each registry needs. They can drop some characters from their repertoires. IG41 would have registries to set an upper limit. * IG40 there was skepticism of having a community to generate a huge group of variants on this topic like the Latin Generation Panel * At the top-level there cannot be diacritics as variants. But at the 2nd level diacritics can be defined as variants and many like .cat already do this. It should really be variants in this IG40. If they don’t have to take care of variants and diacritic sets, only with LGRs and variants, both technically and policy wise. * “Minimum variant relationships” question. How does one ensure that the relationships are retained and not removed? Minimum variant relationships could be updated. The idea is that all diacritic characters are considered variants. Registries may change the latin script diacritic LGR may change it because they don’t want to use the whole set of latin characters. The intent is to say the registry can change the LGR, but not drop the variant relationship between diacritic characters. * Should emphasize that none of this changes the RZ-LGR, this is only at the second-level. Recommendations should just task ICANN org to come up with something workable and registries could choose to adopt it and customize it for their own needs. * Sarmad: when everything is allocatable variant apart from being not very conservative as LGR design has a conservatism principle. This is in some ways going in the other direction. There can be very significant amount of corner cases for a large set of diacritics. Starting with the cases clearly not possible and still allocatable seems like something it is normally not designed for. This is why giving an overall allocation, the script community could look at it to make a usable set, but not make an unlimited allocatable set. * Sarmad: When something is blocked it is easier to make it allocatable, which is why the conservatism principle as this will be a reference LGR. It can be changed per the registry requirements, that is flexible. Making things slightly more conservative does not close doors for a different solution. * Michael: Intention of the LGR to have the same entity set to be upheld and the disposition value of blocked or allocatable. Could instead say something like the reference LGR created by ICANN makes all these variants blocked per default, but registry is free to make them allocatable if their language or use case requires this. * IG41 agreed upon previously and summarized in the slide * Recommendation X overview given in the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> reminding the WG of PR3. * Rec X proposed language clarifies that one can add to existing TLDs. * There could be a similar ruling for variants belonging to separate entities and could be exempted from the rules, but no new cases could be granted. * Sarmad: sharing with string sim panel currently, there is not a clear mechanism to take this message to SSR panel. Their work is dependent on policy from SubPro and IDN-EPDP Phase 1. * Recommendation X would be discussed again next week based on Sarmad’s input. * PR18 and PR19 discussed based on the Board input provided at ICANN86 summarized on slide<https://icann-community.atlassian.net/wiki/x/AQAwR> 13 and the Board email sent via LD PDP mailing list on 24 June. * The WG tried to follow IDN-EPDP and they were copied and follow the same recommendations. So this was indeed a precedent following that. * Application fee is a cost recovery principle and that was fine. Operational cost is a different topic. IDN PDP was to incentivize adoption of IDNs and variants to make it easier to apply for these. The mandate for the LD PDP is the opposite, it is an exception process. * The Board feels that this is a precedent, the fact of saying how much the fees should be is something that is in ICANN org’s discretion. This is not in the remit of the PDP. Even if the WG believes it has reached the right conclusion, it is not worth hitting a wall with the Board and should not delay the whole thing because of these recommendations. Proposed deleting these recommendations. * How strongly does the WG feel about this? Is it worth delaying the whole PDP? Proposal to change language to should and could be at the implementation decision level. * Path forward: Discard recommendations 18 and 19 as they are not necessary for the policy to work. * Suggestion to change the language of 18 and 19 for alternate language to get to the intent of the WG to increase likelihood of acceptance by the Board. Suggestions to change the language from must to should * Prices are not in the remit of the PDP. * Changing must to should would not have much of an effect. The Board is saying please don’t make the recommendations. Policy development groups cannot set ICANN fees period. Proposal to simply take away these recommendations. Can explain in the final report that this was debated, but it is not within the remit of the WG. * Whether it is suggested in should or must, that is not allowed for the WG to discuss. * Steve: concern exists on the number of applicants or operational support needs at the time of implementation. He emphasized the concerns of Amadeau, that it is not within the remit. * WG did not object to discard recommendations 18 and 19 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> for the HRIA<https://docs.google.com/spreadsheets/d/1LkcqfulRQiNEM4tjFzCeiISbU1p5x5UuE_H…> public comment. The Public Comment is mostly geared towards future PDPs from Public Comment review as there are no actions for this. * PR 14 was updated to the group for the proposed path forward. 14.3 and .BRAND. Clarified on slide<https://icann-community.atlassian.net/wiki/x/AQAwR> 18 for a stricter rule than trademark law as determined by the EPDP-IDNs. * PR14 resolved 4. Next Steps 5. AOB Thank you, 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

Message from ICANN Board
by Michael Bauland June 24, 2026

June 24, 2026

Dear LD WG members, a few minutes ago, I have received a message from ICANN board and have been asked to relay it to the full group. We will discuss this in the upcoming call in one hour. Cheers, Michael Message from Board: Dear LD PDP WG, As the ICANN Board members serving in place of the late Alan Barrett following his unfortunate passing, we would like to relay the ICANN Board’s concerns regarding Recommendations 18 and 19. After careful consideration of the issues surrounding Recommendations 18 and 19 in the LD PDP, the ICANN Board has concerns that they may not be adoptable. The Board recognizes that registry-level fee setting is within ICANN org’s discretion and would like to preserve that discretion and avoid setting precedents in policy development that are within ICANN’s operational remit. The Board appreciates the WG’s hard work and dedication and looks forward to the WG reaching a well-informed decision that aligns with ICANN’s long-standing mission that will help ensure a stable, secure operation of the Internet’s unique identifier systems. Kind regards, Amitabh Singhal and Chris Buckridge -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland(a)knipp.de Software Development E-mail: Michael.Bauland(a)knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp Certified according DIN ISO/IEC 27001:2017

4 3

Meeting link
by anil Jain June 24, 2026

June 24, 2026

Saewon, Greetings of the day! Can you please share meeting link for today’s call at 1315 utc. ? Anil Sent from my iPhone

3 2

Proposed Agenda for Meeting #38
by Saewon Lee June 23, 2026

June 23, 2026

Dear LD PDP WG, I hope those of you who travelled to Seville for ICANN86 are all back home safe and back to your daily routines. Please find below the proposed agenda for LD PDP WG Meeting #38 on Wednesday, 24 June 2026, at 13:15 UTC: 1. Welcome and SOI Updates 2. Recap of LD PDP Working Session during ICANN86 * 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 finalize discussions for HRIA, PR14, PR48, IG52, PR53, IG54, and Glossary as they relate to the public comments received. Please review the Public Comment submissions in their entirety through the Public Comment Review Tool here: 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 the dedicated Public Comment page for LD PDP WG here: https://icann-community.atlassian.net/wiki/x/BIAUM Looking forward to seeing you all tomorrow! Best regards, 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

ICANN86 Notes, Outcomes, and Action Items
by John Emery June 10, 2026

June 10, 2026

Dear LD PDP WG, It was great to see many of you in person at ICANN86 and many thanks to those of you who joined remotely. Please see below the attached notes, outcomes, and action items from the ICANN86 LD PDP WG meeting. [OUTCOMES] * WG agreement on updated language for PR 1 * WG agreement on PR40 that the 2nd level must also retain the same entity principle. [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> and the proposed draft after each WG Meeting and provide input, if any. * Staff and Leadership to review PR X to ensure that the language in the rationale accounts for a case where an LD can be applied for if one currently has an existing ASCII would account for this in PR 3. * WG to consider the Board input on PR18 and PR19 to discuss at the next LD PDP WG meeting * [NOTES] 1. Welcome and SOI Updates 2. Remembering Alan Barrett, Board Liaison to the LD PDP WG * The WG and the Board paid tribute to the life and legacy of Alan Barrett. A tribute to him and his accomplishments can be found on slide 5<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> 3. Recap of Meeting #37 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> and the ICANN Board raised an issue that Alan discussed to the Board before his untimely passing. * The Board members present Amitabh Singhal and Chris Buckridge gave an update to the LD PDP WG on PR18 and PR19 related to fees. In sum, the Board has concerns about recommendations related to fees, which are at the discretion and in the remit of ICANN org. Furthermore, there was a clear debate and discussion surrounding EPDP-IDN’s Final Recommendations 7.4 and 7.5 that they would be a non-precedent setting recommendation. By following these specific recommendations, it appears to the Board that the LD PDP is following the precedent. There is a distinct difference between EPDP-IDNs, which were intended to incentivize adoption of IDN variants, while LD PDP is meant to be an exceptions process and should take a more conservative approach. Given the untimely passing of Alan, the Board would need additional time for a formal response, but they noted this should not hold up the work of the LD PDP. This informal meeting conveys the essence of the Board’s concerns on this topic. * PRX recommendation discussed and the intended meaning is that it is not possible to have them operated separately and/or applied for separately. * Bill: concerned that someone might already have an ASCII diacritic they would need to effectively make a new application. We need to get the wording clear that it's allowable * Saewon: We do have a separate recommendation on applicants submitting a new application for an already existing gTLD but this point can be added to the rationale. Preliminary Recommendation 3: Consistent with Final Recommendation 3.2 of the EPDP-IDNs Phase 1 Final Report, a future gTLD registry operator wishing to apply for a corresponding ASCII gTLD or Latin diacritic gTLD(s) of their existing gTLD must submit an application during an application round. * PR 1 discussed allowing for a more expanded scope beyond the early unicode decomposable table discussed on slide <https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> 10. Emphasis placed on the deep deliberations that took place to get this point. * PR 39 updated language noted * Figure 3 updated to make it more user friendly and the same entity principle as outlined in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…>. * Query from Ariel about harmonization of LD and Variant tables. Michael responded that there is this requirement, but this case is still theoretically possible. The LGRs harmonized does not mean they have to be the same. They just have to be consistent. * Edge case examples of Figure 3 outlined in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…>. * PR 40 and case 1.3 discussed as previously this was allowed to be the registry to decide. If at the TLD it has to be the same entity, then at the 2nd level the registry could just decide. This could cause more user confusion. Consequence during last call is that all 2nd level labels must now belong to the same entity as well 4. Review of LD PDP Initial Report Public Comment * Saewon outlined the Human Rights Impact Assessment based on the Public Comment with a summary in the slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/11009418…> but she encouraged all to review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4B…> * She gave an overview and highlighted for the proposed path forward based on the HRIA and GPI Public Comments, strengths were many, but there were a few improvements for the Final Report. This was a lot related to implementation or future work. Much was not relevant to the current working group, it could be detailed further within the final report of the HRIA 5. Review of Proposed Table of Contents for Final Report 6. Consensus Call Process Reminder 7. Work Plan and Next Steps 8. AOB Thank you, 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

Same entity on 2nd level
by Tapani Tarvainen June 3, 2026

June 3, 2026

Thinking of the test.domain vs tést.domain scenario, I find myself concluding that enforcing the same entity principle on 2nd level domains is not viable. Confusion potential is real, but as it already exists for extant TLDs, ASCII as well as IDN ones, and we cannot do anything about those, can or should we enforce stricter rules for our case? Same entity requirement on 2nd level could also have some undesirable side-effects. What would happen if cafe.quebec and café.quebec were already extant with different registrants when .québec is applied for? Should that block .québec application? Or should the policy have some kind of grandfather clause? I don't see why café.quebec and cafe.quebec would be less likely to cause confusion than cafe.québec and café.québec. If anything the latter should be safer simply because people using .québec are more likely to pay attention to accents. Likewise, sakki.fi, säkki.fi and šakki.fi (all extant domains with different registrants) are unlikely to confuse Finnish speakers, and others are less likely to use .fi domains. I guess we could require applicants to document their policy in this regard, perhaps including that they must alert registrants to the issue, but I would not insist on strict same entity principle on 2nd level. I remain, however, open to persuasion. :-) -- Tapani Tarvainen

7 11