We could submit the draft-ietf-eppext-idnmap-02 to IANA again, but the extension uses the IETF namespace “urn:ietf:params:xml:ns:idn-1.0” which is already claimed by a non-IETF clone with IPR attached. if the XML schema of draft-ietf-eppext-idnmap-02 and the clone are identical, then a easy fix can be replacing the current clone by the “official” IETF version. this would then not cause issues for clients, as the XML has not changed.
- Maarten > Op 7 nov 2025, om 10:23 heeft Gould, James > <[email protected]> het volgende geschreven: > > 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] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
