Speaking as a participant: Thanks Jiankang for the question.
There’s another important difference to consider. This new work is more general than variants. It is based on the principle of domain names in a shared central repository that are tied to a “same entity”. With this generality the extension can also be used by sets of labels where the labels are distinguished by the use diacritic marks, which are not considered variants by the generally accepted definition of a variant. We will review this relationship with the working group and will include a summary of this discussion in the final document. Jim On 19 May 2026, at 3:24, Michael Bauland wrote: > Hi Jiankang Yao, > > Am 19.05.2026 um 05:58 schrieb Jiankang Yao: >> I think that variants work is very important. >> >> I would like to know the relationship between this draft and RFC9095 >> "Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for >> Strict Bundling Registration”. > > thanks for you question. The main difference is that for RF9095 domain > registrations, the bundle of domain names is kind of fix (depending on the > registry policy). When you register one domain, you get the bundled domain(s) > automatically activated and assigned to you. > > The new extension draft-galvin-regext-epp-variants does not automatically > activate any variants (at least not necessarily, it could also be used to > activate (some) variants automatically). Potentially available variants can > be added to existing domains via the extension. Similarly, variants can be > deactivated again, in case they are no longer needed. > > This is in particular necessary for Scripts with an almost unlimited number > of allocatable variants (e.g., Arabic). There can be domain names that have > billions of available variants, but the registrant possibly just wants to > activate two or three of them. Using the RFC9095 approach would result in the > registry activating all of those billion variants (or any subset that might > not match the ones the registrants intends to activate). > > So, the new extension gives the registries and registrars the freedom to > decide on a case-by-case basis, what variants should be activated and when. > > 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]
