Thomas, The issue here is that if ICANN requires the extension to be registered, and the extension is an abandoned IETF draft, then the namespace would need to be registered with the MUST language. The alternative approach is to clone the IETF draft as a proprietary extension. The proprietary extensions should not include an ietf namespace, but we've seen that occur with draft-ietf-eppext-idnmap. Changing the namespace is a material impact to the server and the clients that chose to implement a draft that was abandoned prior to becoming an RFC. I don't recommend creating a set of proprietary extensions of abandoned drafts that then can be registered in the extension registry.
The TANGO IDN extension is a pure proprietary extension using a custom namespace, so there is no issue with registering it. As noted, the implementation of an abandoned draft is a corner case that can't be ignored with the requirement to register implemented extensions in RST 2.0. The SHOULD language in draft-ietf-regext-ext-registry-epp provides the needed guidance while covering the corner case. Another important aspect is that we should encourage more registrations of implemented EPP extensions than less. Based on the EPP Extensibility and Extension analysis, we analyzed 67 EPP extensions and there are only 39 registered EPP extensions in the registry. I view having the registration as less glorifying but providing visibility to registries and registrars of the implemented EPP extension. -- 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 10/21/25, 10:00 AM, "Thomas Corte (TANGO support)" <[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. Hello, James Gould wrote: >> The ICANN RST 2.0 requires for the extensions to be >> registered in the EPP extension registry, which then required the >> registration of >> the implemented "Verification Code Extension for the Extensible Provisioning >> Protocol (EPP)" (draft-ietf-regext-verificationcode-06) that would not be >> able to >> register the IETF namespace. I believe the same use case applies to the >> abandoned IDN Mapping draft in draft-ietf-eppext-idnmap-02, which has been >> implemented by many registries and registrars. Changing of the namespace is >> not an option based on the implementation impact and interoperability with >> the >> registrars. This is a true corner case, but it needs to be covered with a >> SHOULD >> instead of a MUST. I'm aware that ICANN requires registration in the EPP XML registry, but do they also strictly require the *namespace* to be registered as well? I happened to do both for our recent registration of the TANGO IDN extension, but I *think* ICANN would be OK with only the extension being registered. Scott Hollenbeck wrote: > [SAH] I could use some additional perspectives on this, people. Andy is > saying MUST. Jim is saying SHOULD. More input would be helpful. Assuming that ICANN accepts registered extensions whose namespace isn't also registered, I'd tend to go with MUST, if only to avoid "glorifying" abandoned extensions via an IETF namespace in the registry. /Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: [email protected] <mailto:[email protected]> Germany _______________________________________________ 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]
