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