Gavin, The extension registration requirements for RST 2.0 are impactful to the EPP Extension Registry and the language in draft-ietf-regext-ext-registry-epp for being able to register extensions. This is the language that you reference:
All `<objURI>` and `<extURI>` element(s) in the `<greeting>` **MUST** correspond to entries in the EPP Extension Registry. This means that all extensions (object mapping and command-response extensions) must be registered in the EPP Extension Registry, which would apply to the following use cases: 1. Proprietary extensions - IDN EPP Extension for the TANGO Registration System (https://www.tango-rs.com/epp/tango-idn-epp-extension.pdf) is a recent example Registration would be allowed and must have a custom namespace 2. individual IETF drafts - Balance Mapping (https://datatracker.ietf.org/doc/html/draft-gould-regext-balance) would be a recent example that could be implemented ahead of the next standardization steps Would an EPP server need to pre-register the individual draft, or wait for the RFC to implement? 3. Active working group IETF drafts - TTL Extension (https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl) was in this state prior to becoming RFC 9803 Would an EPP server need to pre-register an active working group IETF draft? 4. Past working group IETF drafts that are now RFCs - Registry Fee Extension (draft-brown-epp-fees-04) that is now RFC 8748 I believe this should not be registered in any scenario, so the EPP server would need to upgrade to RFC 8748 ahead of the RST 2.0 test≈ 5. Abandoned working group IETF drafts - Verification Code Extension (draft-ietf-regext-verificationcode-06) and IDN Mapping (draft-ietf-eppext-idnmap) This use case forces the registration of the Verification Code Extension (draft-ietf-regext-verificationcode-06) One approach is to clone the draft for #2, #3, #4, and #5 as a proprietary extension and then register it, so it would morph into a set of #1. The main question is what namespace is allowed for the registration, which needs to be covered in draft-ietf-regext-ext-registry-epp. There is one registered extension that cloned and kept the IETF namespace. Are you looking to adjust the RST 2.0 requirement language or do we need to account for these use cases in draft-ietf-regext-ext-registry-epp? 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/23/25, 11:37 AM, "Gavin Brown" <[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. 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://secure-web.cisco.com/1TlcsOJedh1FpcZb2iV5Mp2FkNyH7lBdzkGDCiUbAxN3JtomnGamxCKXCZIKTUPydvGHYPDEzzoUk-FAfpGrfCQI_aLsTuT-roJVUh4YxbrfeK7VxWasOFD6QRD0eyxtZXOWDmpZm39drjwrZwfUQZ0FuMfuCqM28qbsh2hf-6OR0anxb3WXau7zxvySd56UtTT2giIeB5c9BBlVTrK1IUFeh9TscMPeSEmXFx_ASJzf6Taa8MgN0Yn9u56MEMHc8FUjYqkVr_SCDxqEX6vGTqXowE306Nl6wFdZd_JkwN3Q/https%3A%2F%2Ficann.github.io%2Frst-test-specs%2Frst-test-specs.html%23Test-Case-epp-02 <https://secure-web.cisco.com/1TlcsOJedh1FpcZb2iV5Mp2FkNyH7lBdzkGDCiUbAxN3JtomnGamxCKXCZIKTUPydvGHYPDEzzoUk-FAfpGrfCQI_aLsTuT-roJVUh4YxbrfeK7VxWasOFD6QRD0eyxtZXOWDmpZm39drjwrZwfUQZ0FuMfuCqM28qbsh2hf-6OR0anxb3WXau7zxvySd56UtTT2giIeB5c9BBlVTrK1IUFeh9TscMPeSEmXFx_ASJzf6Taa8MgN0Yn9u56MEMHc8FUjYqkVr_SCDxqEX6vGTqXowE306Nl6wFdZd_JkwN3Q/https%3A%2F%2Ficann.github.io%2Frst-test-specs%2Frst-test-specs.html%23Test-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://secure-web.cisco.com/1wZMptQ99UY4GX4RUAlE7Yr5A4PCW_GXbgHn-x34NAs31CrH6SM5sX91YOhU5B7ZRMmiVhMYutjG445GtLH3pAUXF4XZAA_PSWP1ROvV4zm-EQhQckLJPR-mynOsFGlBa-W1sagx6FcSxms_E1o_q5SlXQrL5Cg1A7v5AJyRwWcFPklnFDRXHUvtY54D_dAdlHcVCyW-j7UdTEx5HtVMpuGrWxY5OL_mS6l7QviIZBClnAFXTMDuamyONJqDpjidF19NF4Vob1j9kXuQ008fNbU-q7zPOlFJxvrte3GAby-c/https%3A%2F%2Fgithub.com%2Ficann%2Frst-test-specs%2Fpull%2F114%2Ffiles <https://secure-web.cisco.com/1wZMptQ99UY4GX4RUAlE7Yr5A4PCW_GXbgHn-x34NAs31CrH6SM5sX91YOhU5B7ZRMmiVhMYutjG445GtLH3pAUXF4XZAA_PSWP1ROvV4zm-EQhQckLJPR-mynOsFGlBa-W1sagx6FcSxms_E1o_q5SlXQrL5Cg1A7v5AJyRwWcFPklnFDRXHUvtY54D_dAdlHcVCyW-j7UdTEx5HtVMpuGrWxY5OL_mS6l7QviIZBClnAFXTMDuamyONJqDpjidF19NF4Vob1j9kXuQ008fNbU-q7zPOlFJxvrte3GAby-c/https%3A%2F%2Fgithub.com%2Ficann%2Frst-test-specs%2Fpull%2F114%2Ffiles> G. > On 22 Oct 2025, at 17:44, Gould, James <[email protected] > <mailto:[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] <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 > <https://secure-web.cisco.com/113hJzMdWN8V1_txFLvitbzAkWF9H1_ZPny2RZUFvgU3arJbkhUC9p2mJlbiM7bKiE0qKmBU8twlXrJk7ZGJrOeQRLkT_ZbZnLcvbhh5PaIfVtfa52Q3PVNnV5D7XCuNc4lMh-JJhqund1zglPHpYiyuCYr1-USkcmluwDqUUxBZS24KudwUvAsC4sumZIsX2baDIi2bMgYCjiEKSAmfTQk35ZfDqhiYhNSfdQY2_D4Z6IjplCyhLogObrK851u0Oc8yvzqvBfQ4UsFG2b5N4zhtqVnpF-kmytQN_Y6l683k/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fverisigninc.com%2F__;!!PtGJab4!9rlBO8VxLhNLxNC60OINKexVnaeykcutKYsnpRCJ3ATHSwDoX_5R9-dt3t9Jhr0kl2PB4SumN5Zib2Lp4U1nrr5I_UEFnfDsMAk7v8Ng$ > > <https://secure-web.cisco.com/113hJzMdWN8V1_txFLvitbzAkWF9H1_ZPny2RZUFvgU3arJbkhUC9p2mJlbiM7bKiE0qKmBU8twlXrJk7ZGJrOeQRLkT_ZbZnLcvbhh5PaIfVtfa52Q3PVNnV5D7XCuNc4lMh-JJhqund1zglPHpYiyuCYr1-USkcmluwDqUUxBZS24KudwUvAsC4sumZIsX2baDIi2bMgYCjiEKSAmfTQk35ZfDqhiYhNSfdQY2_D4Z6IjplCyhLogObrK851u0Oc8yvzqvBfQ4UsFG2b5N4zhtqVnpF-kmytQN_Y6l683k/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fverisigninc.com%2F__;!!PtGJab4!9rlBO8VxLhNLxNC60OINKexVnaeykcutKYsnpRCJ3ATHSwDoX_5R9-dt3t9Jhr0kl2PB4SumN5Zib2Lp4U1nrr5I_UEFnfDsMAk7v8Ng$> > [verisigninc[.]com]> > > > > > On 10/22/25, 11:54 AM, "Thomas Corte (TANGO support)" <[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. > > > 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]> > <mailto:[email protected] <mailto:[email protected]>> > Germany > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://secure-web.cisco.com/15TaKKa_9HWfRKIZPMOCJ7a1HlWMtNsA5kyPlIigo4qqs9pfTe4CC-IIvHgXsMJsuxcfsVWC2lx_m1lDN1PVAy052lmpA9HatjNLCHSLWwKiVb0eSED9bJ2WX3ztGeOMQtyh_a6qd2FSxjs1Ak50KRmrQ-lOpj5sooS4ywjHYUn38yjb_AaudolWD_J1K0Qi_9mCZ6OzgEcVcEKvqwRxBj8biKZkFsu6c0nMT7Mi2foxXIjjQRV0HadKr-t7wozAdiU1BnsMkARhHn6l2CWqxUrj4cytm02iKKfinX4YLc0Y/https%3A%2F%2Fwww.icann.org <https://secure-web.cisco.com/15TaKKa_9HWfRKIZPMOCJ7a1HlWMtNsA5kyPlIigo4qqs9pfTe4CC-IIvHgXsMJsuxcfsVWC2lx_m1lDN1PVAy052lmpA9HatjNLCHSLWwKiVb0eSED9bJ2WX3ztGeOMQtyh_a6qd2FSxjs1Ak50KRmrQ-lOpj5sooS4ywjHYUn38yjb_AaudolWD_J1K0Qi_9mCZ6OzgEcVcEKvqwRxBj8biKZkFsu6c0nMT7Mi2foxXIjjQRV0HadKr-t7wozAdiU1BnsMkARhHn6l2CWqxUrj4cytm02iKKfinX4YLc0Y/https%3A%2F%2Fwww.icann.org> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
