Thanks again, Jim. It's my opinion that we have multiple IDN-related extensions and one independent stream RFC because we don't have a well-defined strategy to address whatever issues there are with IDN registration and management. I'd really prefer to see a draft that attempts to define that strategy before we adopt a standards-track draft that describes an approach that can be used to manage variants, but you're right. That's something the WG needs to decide.
In the absence of an agreed-upon IDN strategy I'm unsure if this draft describes the best way to deal with variants. That causes me some concern about it becoming a standards-track RFC. However, if "variants" never came up in the discussion, and we were just talking about "sets of objects", I wouldn't have that concern. I'm OK with adopting the draft. We can always pause or redirect the work in the future if the IDN bits become problematic. Scott > -----Original Message----- > From: James Galvin <[email protected]> > Sent: Thursday, May 21, 2026 3:03 PM > To: Scott Hollenbeck <[email protected]> > Cc: Antoin Verschuren <[email protected]>; draft-galvin-regext-epp- > [email protected]; [email protected]; [email protected] > Subject: Re: [regext] Call for adoption: draft-galvin-regext-epp-variants-05 > (Ends 2026-05-25) > > Speaking as a participant: > > I leave it the working group, should it adopt this work, to decide if it wants > to have an IDN strategy. If it does, I would expect this work to be part of > that. > > It’s important to keep in mind that this work is not “limited” to IDNs. This > work is about manipulating a set of objects where the set is defined by the > registry. At least one additional type of set of objects we know about is a > set of labels distinguished by the use diacritic marks. There may be others. > > Of course, as one of the purposes of REGEXT is to seek to harmonize and > standardize extensions in both EPP and RDAP, we will review all > extensions currently registered and review their relationship to this work. > We will include a summary of that review in the final work product > developed here. > > As far as whether or not this document is the “one to rule them all”, that is > up to the working group to consider. We are currently proposing a specific > scope: manipulating sets of objects. We expect that this covers the > manipulation of variants. However, it is possible that as the working group > reviews all existing registered extensions there is a use case we have not > considered, in which case the working group will have to decide what to do > about that. Obviously we could either evolve this work to cover the use > case or consider that use case out of scope. > > I hope I have responded to your concerns. > > Jim > > > On 18 May 2026, at 14:55, Scott Hollenbeck wrote: > > > 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. > > > > Scott > > > >> -----Original Message----- > >> From: James Galvin <[email protected]> > >> Sent: Monday, May 18, 2026 10:24 AM > >> To: Scott Hollenbeck <[email protected]> > >> Cc: Antoin Verschuren <[email protected]>; draft-galvin-regext-epp- > >> [email protected]; [email protected]; [email protected] > >> Subject: Re: [regext] Call for adoption: draft-galvin-regext-epp-variants- > 05 > >> (Ends 2026-05-25) > >> > >> Speaking as a participant: > >> > >> These are very good questions Scott. I’ll make two comments in > response. > >> > >> First, one obvious difference is that we’re proposing this document to > be > >> on the Standards Track. So, if we successfully find consensus in the > >> working group for this document then that’s how we’ll be listed against > >> those proprietary extensions. > >> > >> Second, it has always been our intention to answer these questions. > >> Personally, I believe it is clearly within the Charter of REGEXT, and thus > this > >> working group, to seek to unify compatible extensions in the registry > into a > >> single standard. It is my opinion that that is one of the primary reasons > >> this working group exists. In prior versions of the internet draft you may > >> recall seeing a comment to effect of answering these questions directly > in > >> the document so the intention was always clear. It was moved to being > an > >> issue for the draft, but that’s not visible yet to the working group. If > >> the > >> document is adopted by the working group we will be moving the > >> document to the IETF GitHub and we’ll use the Issue Tracker there to > call > >> this and other issues out to help manage the document. > >> > >> Thanks for the call out! > >> > >> Jim > >> > >> > >> On 12 May 2026, at 6:56, Scott Hollenbeck wrote: > >> > >>> I don't yet have an opinion. I'd like to understand how this extension > >> compares to the other EPP variant extensions that are already > registered in > >> the EPP extension registry, including: > >>> > >>> https://www.tango-rs.com/epp/tango-idn-epp-extension.pdf > >>> > >>> https://corenic.org/epp-extensions/core-idn-epp-extension-1.0.pdf > >>> > >>> https://ngboss.ngtld.cn/EN/view/noside/cnnic-idn-epp-extension- > >> 1.0.html > >>> > >>> Is the goal to somehow unify all of these extensions, or will this be yet > >> another EPP IDN extension? > >>> > >>> Scott > >>> > >>>> -----Original Message----- > >>>> From: Antoin Verschuren via Datatracker <[email protected]> > >>>> Sent: Monday, May 11, 2026 10:31 AM > >>>> To: [email protected]; [email protected]; > >>>> [email protected] > >>>> Subject: [regext] Call for adoption: draft-galvin-regext-epp-variants- > 05 > >>>> (Ends 2026-05-25) > >>>> > >>>> This message starts a regext WG Call for Adoption of: > >>>> draft-galvin-regext-epp-variants-05 > >>>> > >>>> This Working Group Call for Adoption ends on 2026-05-25 > >>>> > >>>> Abstract: > >>>> This document defines an EPP extension allowing clients to learn > >>>> about and manipulate a set of objects in a shared central > repository > >>>> that are necessarily tied to the same entity (typically domain > >>>> objects whose names are equivalent in a registry-defined way and > are > >>>> tied to a single registrant). The extension supports multiple > >>>> registries with a shared definition of equivalence using a shared > >>>> central repository. > >>>> > >>>> Please reply to this message and indicate whether or not you support > >>>> adoption > >>>> of this Internet-Draft by the regext WG. Comments to explain your > >>>> preference > >>>> are greatly appreciated. Please reply to all recipients of this message > >> and > >>>> include this message in your response. > >>>> > >>>> Authors, and WG participants in general, are reminded of the > >> Intellectual > >>>> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > >>>> Appropriate IPR disclosures required for full conformance with the > >>>> provisions > >>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > >>>> Sanctions available for application to violators of IETF IPR Policy can > be > >>>> found at [3]. > >>>> > >>>> Thank you. > >>>> [1] https://datatracker.ietf.org/doc/bcp78/ > >>>> [2] https://datatracker.ietf.org/doc/bcp79/ > >>>> [3] https://datatracker.ietf.org/doc/rfc6701/ > >>>> > >>>> The IETF datatracker status page for this Internet-Draft is: > >>>> https://datatracker.ietf.org/doc/draft-galvin-regext-epp-variants/ > >>>> > >>>> There is also an HTML version available at: > >>>> https://www.ietf.org/archive/id/draft-galvin-regext-epp-variants- > 05.html > >>>> > >>>> A diff from the previous version is available at: > >>>> https://author-tools.ietf.org/iddiff?url2=draft-galvin-regext-epp- > >> variants- > >>>> 05 > >>>> > >>>> _______________________________________________ > >>>> regext mailing list -- [email protected] > >>>> To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
