Hi Scott,
Am 18.05.2026 um 20:55 schrieb Scott Hollenbeck:
Thanks, Jim. I'd very much like to discuss the idea of having an IDN extension on the
Standards Track, but it begs the question of "what is the WG's IDN strategy?".
We don't have one, so how this draft relates to existing extensions is something we need
to decide. I'd very much like to see opinions from the people who created those other
extensions, if they're still around. Do they agree that this draft is the one to rule
them all? Do they agree with the scope? I agree that the draft fits within the WG's
charter, but the charter doesn't address the topic of IDNs at all.
thanks for asking for the opinion from the authors of other existing
extensions. I can speak for two extensions:
https://www.tango-rs.com/epp/tango-idn-epp-extension.pdf
https://corenic.org/epp-extensions/core-idn-epp-extension-1.0.pdf
These have been created by us, and yes, we're still around (and the
extensions are in use).
While these extensions have several features that are also available in
the new draft, there are two major things missing.
1. There is the concept of primary domain names. These existing
extensions have two different modes: variant-as-attributes and
variants-as-objects. In the former, a primary domain exists, but only a
single one and we potentially need one primary per TLD in case of
variant TLDs (or Latin Diacritic Script TLDs). In the latter case
(object) there is no concept of primary domains. All activated domains
in a variant set are equal to each other. This is ok for the IDN tables
we are currently using in our TLDs, but it does not work for LGRs with
asymmetric variant disposition (like ICANN's reference Latin LGR).
2. Another issue with those two existing extensions is that the same
entity principle for registrants needs to be checked on the registry
level (i.e., by checking that the same registrant contact handle is used
in all variant domains). This works for our TLDs as we still require the
registrant contact to be submitted, but many other registries have moved
to the thin model and don't have that information available. So these
extensions wouldn't work for them. In the new extension
draft-galvin-regext-epp-variants we have moved the responsibility of
checking for the same registrant to the registrar level. To avoid
accidental activation of variants, the registrar has to confirm (via the
extension) to the registry that they have checked this.
So, back to your question: yes the new extension is intended to work in
all situations and should replace the different existing extension.
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: [email protected]
Software Development E-mail: [email protected]
Register Court:
Amtsgericht Dortmund, HRB 13728
Chief Executive Officers:
Dietmar Knipp, Elmar Knipp
Certified according
DIN ISO/IEC 27001:2017
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
