Thomas, I'm not proposing that "urn:ietf:params:xml:ns:fee-0.7" should be registered in the EPP extension registry for any reason. If the RST 2.0 requirement did require draft extension versions to be registered, then the registration request of "urn:ietf:params:xml:ns:fee-0.7" would be a negative side effect. Attempting to register a draft extension (e.g., "urn:ietf:params:xml:ns:fee-0.7" in draft-brown-epp-fees-04) when there is later RFC registration (e.g., " urn:ietf:params:xml:ns:fee-1.0" and RFC 8748) should be rejected. The attempt to register a proprietary extension that is a copy of a draft extension with the exact same XML namespace should also be rejected. Copying a draft extension and changing the XML namespace would be accepted, but that would fragment the extensions based on the number of registries that implement the draft extension and need to register their implementation in the EPP extension registry to meet the RST 2.0 requirement.
Andy, can you clarify the RST 2.0 registration requirement, since that requirement is what would drive the need to register a draft extension, such as the following: 1. Do all implemented extensions need to be registered? 2. Do only implemented proprietary extensions need to be registered? 3. Is there a distinction between the different types of IETF drafts (e.g., individual draft, active working group draft, abandoned working group draft) that need to be registered? I don't believe there would be the natural desire to register draft-brown-epp-fees-04 with the "urn:ietf:params:xml:ns:fee-0.7" namespace. The hope is that the registries would naturally implement the RFC version within a reasonable period (draft-brown-epp-fees-04 was published on February 17, 2015, and RFC 8748 was published in March 2020). Thanks, -- 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/22/25, 11:54 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, On 22.10.25 17:32, Gould, James wrote: > Does the RST 2.0 registration requirement also apply to implementations of > active extension > drafts? Imagine that a registry implemented a draft version of the registry > fee extension prior > to it becoming an RFC and the registry needed to pass RST 2.0. Would the > registry need to > register the draft version in the EPP extension registry or worse yet copy > the draft extension > and register it as a proprietary extension retaining the IETF namespace? The > XML namespace is > not easily changed when registries choose to implement the draft extension, > since it will impact > all registrars using that extension version. The implementation of draft > versions has been done > with EPP from the beginning. Consider the 04/02 days of EPP, when registries > implemented the > -04 version of the base EPP draft and the -02 version of the object mapping > drafts. The use of > point versioning of the XML namespace helped with the 04/02 days of EPP, but > draft versions of > EPP extensions have been implemented with the launch phase extension and the > registry fee > extension to name a couple. I believe we should encourage the implementation > of draft > extensions that hopefully do become RFCs, where there are instances that the > draft extensions > did not progress to RFC. While I agree with the above, I'd also hate to see something like "urn:ietf:params:xml:ns:fee-0.7" being allowed to be registered and thereby possibly established as a permanently acceptable implementation of the fee extension. Working on the registrar side of things, I'm not a fan of having to maintain support for numerous incompatible versions in my client code. In this sense, it's good to see ICANN requiring the use of registered extensions going forward, and I assume they're doing this to make life easier for registrars, as it nudges registries towards (finally, after 5 years) implementing the 1.0 version. Allowing "urn:ietf:params:xml:ns:fee-0.7" to be registered alongside "urn:ietf:params:xml:ns:epp:fee-1.0" would undermine this effort. Best regards, 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]
