Dear LD PDP WG, Please see the attached outcomes, action items, and notes from the WG meeting on 25 March 2026 [OUTCOMES] * PR 6 It should be possible to remove the ASCII TLD if only a single diacritic TLD remains. Two cases with one with multiple TLDs remaining and the sole TLDs remaining * IG 8: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. [ACTION ITEMS] * PR 6 enacted a suggestion to make Latin Diacritic string(s) with the possibility of plural. Then to delineate the two parts of PR 6 with multiple diacritics vs a single diacritic and ASCII. * IG 8 Leadership and Staff to come up with examples to seek to clarify the definition of a set and what can be dropped when the exceptions process is chosen. * WG to think about the suggestion from Tapani and the Mark list and consider keeping with Unicode to continue discussion next week. * WG to focus on reviewing this document to check the draft language from ICANN85 and provide input. https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-E... [NOTES] 1. Welcome and SOI Updates 2. Recap of ICANN85 a. Key Outcomes and Action Items * Went through slides<https://icann-community.atlassian.net/wiki/x/AQBANw> reviewing what happened at ICANN85 through the public comment review tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE...>. Public Comment summary report <https://itp.cdn.icann.org/en/files/generic-names-supporting-organization-cou...> has also been published. * Outstanding action item to revisit recommendations 6, 8, and 50 after reviewing language 3. Review of LD PDP Initial Report Public Comment * Went through slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 7 on PR 6 reviewing ICANN org public comment for discussion * Discussion of application where it is not possible to add anything for the window closed, suggestion to say that future rounds can be stated explicitly in PR 6 rationale * Do we only want to allow the removal of diacritic labels, then the ASCII also must exist? What if the second to last label would be removed? Should it be possible to dissolve the set and allow a single remaining label with an ASCII or LD TLD or does it have to be the ASCII * Here there is an artificial bundle unlike IDNs that * Sarmad: it is two different cases, one with multiple diacritic versions and an ASCII. ASCII must exist and may not be removed, but some diacritic versions could be. Second recommendation is that if there is a situation where one is left with only a single ASCII and single diacritic then either one could potentially be removed. This is two parts of the recommendations or two different recommendations. * Suggestion to have two parts of PR6 * Org comment the applicant can withdraw if it is an ASCII LD set, this is a non-substantive comment to help future applicants to understand what they can/cannot do in applying for a string * IG 8: ASCII/diacritic string vs. label? Should they be the same language? String is used when referring to primary and label refers to variant from IDNs. When we get to application implementation it is just called a string. Strings is generally used * ICANN org comment reviewed on slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 10: context from IDN EPDP there is one principle that the primary is the key to hold the integrity of the set. If primary does not pass evaluation then the entire set will fail. New gTLD for the ASCII/LD set it is not very clear if the ASCII fails evaluation, what happens next? One diacritic could still go ahead with the evaluation phase? * Related to other comments in terms of objection if ASCII is objected to and objector prevails. IDN EPDP does have a recommendation on that, but there is not an equivalent recommendation for LD PDP * What happens if ASCII/LD for remainders of the set if one cannot go forward? * Discussion: it is an unlikely case, but should have a rule for corner cases. Should have a decision if that case exists. * Sarmad: If the primary cannot move forward, then the strings cannot. That somewhat conflicts with PR 6 whether they are a set or not. This inconsistency is coming in this case because in the variant case, the variant can never move forward without the primary. In some cases we are saying here the LD can move forward without the ASCII. Variants depend on primary and our LD string does not, it is independent and only as a requirement. * Solution: be consistent with PR 6 if a diacritic is invalid it can be dropped, but if ASCII is invalid then the set would have to be dissolved and only a single LD could move forward * Sarmad: it may be unlikely, but not impossible, so it needs to be discussed. * IG 8: suggestion would be to be fully consistent with IDN if an LD is invalid then it can be dropped if an ASCII is invalid, then the whole set should be dropped. * Consensus: in case a diacritic gTLD 8.5 accounts for the case when an LD TLD fails the rest can continue. * The open issue is the case if the ASCII fails the evaluation, then what should we do? * The whole application should fail if ASCII fails in line with variant case and add 8.6 * Refer back to PR 5 treating the bundling. In the case that when we apply as a set, it is bundled and it cannot be unbundled in the middle. This is a little different to the evaluation, but was agreed upon. Based on this LD exception process, unbundling the set either of the strings would be allowed to move forward in PR 5. * Going back to the point that was raised for IG 8 if there is agreement that the LD set should be like EPDP IDNs then there should be a corresponding recommendation, which would be 8.6 * PR 5 discussed on slide<https://icann-community.atlassian.net/wiki/x/AQBANw> 11. Cannot switch between standard or exception process. Does that mean once you start with the exception process, or does this also cover when there is only a single TLD process, but it could be viewed as a set with only one element. * Sarmad: When you have one LD string left along with the ASCII, the group then said that either one could be dropped. If very strictly using the set formation and not independent string formation, once you have chosen this, you must stay on this path. It could not be that you could drop ASCII or LD, they could only drop LD or withdraw ASCII, that would make it more consistent with current discussion * Should it be possible to drop an ASCII string and just proceed with a single LD string? Solution 1) As long as a set exists you have to have one ASCII. 2) Should it be possible to dissolve the set and only have the LD TLD and move forward? Or should that be disallowed? Once you start the exceptions process you must keep the ASCII. * IG 8 Consensus: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. * Discussion IG 8: if the ASCII fails evaluation then the entire set fails * IG 8: Once you start with the exceptions process you cannot switch to the standard process you have no ability to drop the ASCII, just like in the variant case you have no ability to drop the primary string. * Discussion of Diacritics via Unicode from list. Non decomposable is out of scope as we have defined it or as it is in the Charter. Is it flexible? This was from the WG decision. * Slide 28 outlined the list discussion for the Unicode vs. Latin small letter with diacritic * Problem is keeping it testable and bounded. How do we test those boundaries? Whatever is decided moving forward it needs to be testable. * Mark came up with additional characters using the theory of Latin small letter with. It would add some unexpected characters, but there is a clean implementation path. Latin small letter with is viable. This does not exactly fit the model of composition of characters. Here there is an arbitrary subset named latin small letter * Suggestion: There's a bug in your code Mark. You should only allow "LATIN SMALL LETTER [A-Z] WITH", exclude non-ASCII letters like EZH * Sarmad: normally when processing strings we are using unicode data files and general category properties for characters. It is an interesting idea to parse the name of the character with a string as suggesting. Wondering whether the existing property structure of unicode could be used in this case from a programmatic point of view. That could be parsed, but generally that is not the practice * Mark: F with the hook would not be an issue as that is already a variant and would be out of scope of our PDP. 4. Next Steps 5. AOB 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>