Hi Jim, This isn't the venue to discuss the niceties of RST v2.0, so instead, I will direct you to the RST test specifications, specifically the epp-02 test case:
https://icann.github.io/rst-test-specs/rst-test-specs.html#Test-Case-epp-02 Note that there is an error in the description of this test case that will be fixed in the next version. A pull request showing the planned change may be found here: https://github.com/icann/rst-test-specs/pull/114/files G. > On 22 Oct 2025, at 17:44, Gould, James <[email protected]> > wrote: > > 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 > <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!9rlBO8VxLhNLxNC60OINKexVnaeykcutKYsnpRCJ3ATHSwDoX_5R9-dt3t9Jhr0kl2PB4SumN5Zib2Lp4U1nrr5I_UEFnfDsMAk7v8Ng$ > [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] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
