Scott, That's the complexity here where there are many independent implementations of a published IETF draft extension. None of those implementors have the copyright for the extension, so how do we get that extension in the EPP extension registry to ensure that it's publicized as an implemented EPP extension without forking and getting into copyright issues? I went through the process to get the verification code extension registered as an implementer of draft-ietf-regext-verificationcode, which felt unnatural, but that may be the only option for this corner case. The registrant is the first one to attempt to register it an abandoned extension. I don't believe additional implementors care if the extension is already in the EPP extension registry, but that is a question. One of the implementers of the IDN map extension (draft-ietf-eppext-idnmap-02) could submit the registration request to get it into the EPP extension registry to publicize its implementation that retains the IETF copyright.
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/7/25, 10:14 AM, "Hollenbeck, Scott" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Jim, the working group can't register extensions on behalf of implementers. That's a job for the implementers themselves, who need to provide contact information, applicable TLDs, etc. as part of the process. This raises another question, though: what should be done if two or more implementers attempt to register the same draft? Do they all get registered separately, or should the registry entry somehow be combined to include information for all implementations? Scott > -----Original Message----- > From: Gould, James <[email protected] > <mailto:[email protected]>> > Sent: Friday, November 7, 2025 9:59 AM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> > Subject: [EXTERNAL] [regext] Re: The IETF XML registry and the EPP Extensions > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > Andy, > > One other recommendation is to have the REGEXT working group proactively > register known implemented abandoned IETF drafts in the EPP extension > registry, which would apply to the IDN mapping extension that looks to have > been implemented by many registries. Those extensions could be considered > for progression to RFC, but since they have the IETF copyright its best to > have > the IETF register them instead of each of the implementing registries. This > would meet the goal of publicizing the implementation of past abandoned IETF > drafts without getting into the negative side effect of forking them as > proprietary extensions on a per-registry basis. I'm unsure how that would > work, > but having an accurate list of implemented EPP extensions in the EPP extension > registry would have helped with the EPP Extensibility and Extension Analysis > work. Again, I would not go down the path of registering the XML namespace in > the XML registry, since they are known non-final extensions. > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE- > B4BA42740803/[email protected] <mailto:[email protected]>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://secure- > web.cisco.com/1a8gFNtQjATGMhcWDGYlYjI8jWFDYkoNRcIv_i2T1nGNW9LruU9 > xYm6Dp9h6ExhfAN7czLIcs- > X2PVYYaeaMDfb0x18xDvE9VZn9b9uH75pW5wEfd6jpadXzppRCUX6iyWImRqtIN- > j2oafoJGr_Z8wMQgzq6oVTMLZcEpgukBr5YAqxZEIkoiszriCoLdQdYSDBTVo1Ceg7I > NxBC32vueRmsBvrm3VJ67VAvhT2MyHGKnHSB2477TcF5QfDNLjMwzskNLZ9coC > wGyDHFlKCwo_564F7otNOdRte8jc2tymzJ04d0Seq8_q0KtLApH5Su/http%3A%2F > %2Fverisigninc.com%2F> > > > > > On 11/7/25, 9:20 AM, "Andrew Newton (andy)" <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > > On Thu, Nov 6, 2025 at 8:38 PM Gould, James <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > To allow I-Ds, the EPP extensions registry could be modified to allow > "provisional" or "early" registrations that sidestep the XML namespace > registration requirements. This is done in many IANA protocol registries > setup by > the IETF, and IANA knows how to periodically check on provisional and early > registrations. > > > > JG - This is an unnecessary step to fulfil the undefined goal in RST 2.0 > > and the > Next Round Registry Agreement. > > > Setting aside this incorrect assertion, if you don't like the "provisional" > registrations then another solution is to use a URI like "file:///dev/null" > in I-Ds > and have IANA assign the URN at publication time according to the provisions > of > RFC 3688 via a note in the IANA considerations section to both IANA and the > RFC editor (for changing examples). This means I-Ds would not be registered > until publication. > > > -andy > > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
