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

final recommendations are in preparation
by Michael Bauland July 14, 2026

July 14, 2026

Hi all, thank you all for your feedback with regards to the recommendations we still had to adjust. We will now finalise everything and review the full set of recommendations, first internally, and then provide you with the final language for your review. We expect this to be forwarded to you next Monday (20th). You then have one week to review the document and we will start the consensus call on Monday 27th. Please let us know, if there are any questions. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland(a)knipp.de Software-Entwicklung E-Mail: Michael.Bauland(a)knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2017

2 1

Exempted Cases (missing Recs) - Please review by end of this week
by Michael Bauland July 10, 2026

July 10, 2026

Hi team, as discussed last Wednesday, we still had to introduce some new policy to deal with the exempted cases. In particular, how the exemption process is finished and what the consequences are. In general, we want the choice to stop the exemption process with the Registry operator and not forced upon them. After all, they may need to change their RSP in order to be able to run an ASCII/LD TLD set. This must remain their own decision. We discussed this with the leadership team and came up with the following Recommendation to be added to our final recs: *Final Recommendation Y (most probably to follow Rec.6)*: /The exemption of gTLDs may result in one of the following circumstances: Y.1 if only a single gTLD remains, and all others have ceased to exist among the exempted ASCII gTLD and all its corresponding Latin diacritic gTLDs; or Y.2 if all gTLDs among the exempted ASCII gTLD and all its corresponding Latin diacritic gTLDs belong to the same gTLD registry operator and are operated by the same Registry Service Provider (RSP), and the gTLD registry operator elects to convert the existing stand-alone gTLDs into an ASCII/Latin Diacritic gTLD set. In consideration of circumstance Y.1, where only a single gTLD remains, the gTLD registry operator wishing to apply for a new corresponding ASCII gTLD or Latin diacritic gTLD(s) of its remaining gTLD must submit an application during an application round in accordance with Final Recommendations 3 and 4. In consideration of circumstance Y.2, where an ASCII gTLD and its corresponding Latin diacritic gTLD(s) belong to the same gTLD registry operator and are operated by the same RSP, the gTLD registry operator may elect to convert all existing stand-alone gTLD(s) into an ASCII/Latin Diacritic gTLD set by submitting a contractual change request to ICANN org outside of any application rounds, provided that no new gTLD is added at the same time and/or a part of the same request. When such conversion is undertaken, the request must include all stand-alone corresponding ASCII/Latin Diacritic gTLD strings that constitute the set. A partial conversion to an ASCII/Latin Diacritic gTLD set is not permitted./ Then, in addition to this new Recommendation, we need to deal with the case that if two existing (exempted TLDs) are merged into an ASCII/Latin Diacritic gTLD set, there can be second level domains, which need to be exempted. If we start with the separate TLDs .cafe and .café, and in both TLD the domain example.cafe and example.café exist, then after the set creation, those two registrations must be exempted from the same entity principle (just like in the IDN EPDP). For this, we adjusted Recommendation 42 as follows (the new part is in red). *Preliminary Recommendation 42 (Final Rec.# TBD):* /Generally consistent with Final Recommendation 3 from the EPDP-IDNs Phase 2 Final Report, immediately prior to the policy effective date of the “same entity” principle as set out in Preliminary Recommendation 40 (Final Rec.# TBD), the existing variant domain names that do not conform to the “same entity” principle must be exempted. Furthermore, where the exempted ASCII and its corresponding Latin diacritic gTLD(s) are converted into an ASCII/Latin Diacritic gTLD set in accordance with Final Recommendation Y, any existing second-level domain names that do not conform to the “same entity” principle must be exempted. This means that there will be no change to the contractual or allocation status of such existing domain names. The requirement of having the same registrant and the same sponsoring registrar will not be applied retroactively. The gTLD registries operating an ASCII/Latin Diacritic gTLD set must determine ASCII/Latin Diacritic Domain Sets for each exempted label and protect from registration all labels in all such ASCII/Latin Diacritic Domain Sets, as appropriate. /Please take a look at these changes and let us know, if you are ok with them or if there need to be any changes. In case you have any questions, please let us know. Please review and provide any comments by the end of this week, i.e., Friday, 10 July 2026, at 23:59 UTC. Then we can finalise the Final Output and send it to you for review. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP:Michael.Bauland@knipp.de Software-Entwicklung E-Mail:Michael.Bauland@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2017

3 6

new board liaison
by Michael Bauland July 8, 2026

July 8, 2026

Hi team, I am happy to let you know that we have a new board liaison to our PDP. Usually, I would have introduced him during our next call, but since there are no more calls, I'll do the introduction via e-mail: Please welcome Amitabh Singhal. For those of you being part of our Seville session, you will have met Amitabh, because he was there, too, talking about the board response. I'm very happy that Amitabh is able to join us, even if we're already nearing the finish line. He's very much interested in our topic and it's good to have him on board. Cheers, Michael -- ____________________________________________________________________ | | | 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

6 10

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