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]

Welcome and SOI Updates
Recap of Meeting #28

a. Key Outcomes and Action Items

Went through slides reviewing what happened at Meeting #28 through the public comment review tool.
PR 6 and IG 8 there needs to be two scenarios for PR 6 with examples given in the slides.
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 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 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 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)