We also need to consider the specialized forms of EPP extensions that were identified in Section 2 of EPP Extensibility and Extension Analysis<https://secure-web.cisco.com/14c-xAbRxt5NA1SHOyH2t6Xg42bpRwjk_qrjwvGJOWnAU69wuuffU3h-rAv30FHtwKihmeJWUgl1h4BiZZh-3pnw7LsXva36PU5lLe5hsedkVVDac6N2HFzVXoR7e2WPJYivgHjNHV02ja2xVqgaeIBTP5LmfMR174PBLsbBTuI5K5KnNnX91kItb99Vl-cC4oTbX5RUq4vCFHecTslQKxbSeCItz69fj-NuJSC-1wIUdSaoYWArnJdnGeDdmTYftbPoorhlmR6a5zdiAUj-Tjg-ooTs7NaCfIQexjS9_5DQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1WR00oB43XZCDqD0zvRvRajuWAq_9wQ3c0RrFKlGC3So>. Two RFCs (RFC 9038 and RFC 9154) that are currently registered don’t any XML elements since they support an operational practice (or profile in RDAP) but only add XML namespaces for signaling support in the EPP <greeting> and EPP <login>. We spent years standardizing these extensions to solve specific protocol problems. Should these extensions be allowed in the EPP Extension Registry? I believe so, but if we strictly scope the definition of an EPP extension that may not make the cut.
Thanks, -- JG [cid87442*[email protected]] 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/> From: "Gould, James" <[email protected]> Date: Thursday, March 5, 2026 at 9:44 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] [regext] Re: WG Last Call: draft-ietf-regext-ext-registry-epp-03 (Ends 2026-03-09) 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. Thomas, "As such, and this is an attempt to get back on topic, I personally wouldn't regards new transports as EPP "extensions" per se, as they don't "extend" the functionality of EPP in the least." Is at the heart of whether EPP transports belong in the EPP Extension Registry. I view all forms of extensibility defined in RFC 5730 as an EPP extension, which includes the ability to define new EPP transports in compliance with Section 2.1, and the forms defined in Section 2.7 "Protocol Extension Framework" that include the guidelines provided in RFC 3735. Based on the Extensibility Analysis in Section 2 of the EPP Extensibility and Extension Analysis<https://secure-web.cisco.com/14c-xAbRxt5NA1SHOyH2t6Xg42bpRwjk_qrjwvGJOWnAU69wuuffU3h-rAv30FHtwKihmeJWUgl1h4BiZZh-3pnw7LsXva36PU5lLe5hsedkVVDac6N2HFzVXoR7e2WPJYivgHjNHV02ja2xVqgaeIBTP5LmfMR174PBLsbBTuI5K5KnNnX91kItb99Vl-cC4oTbX5RUq4vCFHecTslQKxbSeCItz69fj-NuJSC-1wIUdSaoYWArnJdnGeDdmTYftbPoorhlmR6a5zdiAUj-Tjg-ooTs7NaCfIQexjS9_5DQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1WR00oB43XZCDqD0zvRvRajuWAq_9wQ3c0RrFKlGC3So>, the following forms of extensibility is formally supported in RFC 5730: 1. Transport Mapping 2. Protocol Extension 3. Object Extension 4. Command-Response Extension 5. Authorization Information Extension I view all these forms as applicable for the EPP Extension Registry to meet the goal of providing visibility for consolidation of extensions. That’s what is occurring know for the finance-related EPP extensions in draft-ietf-regext-balance<https://secure-web.cisco.com/1A3_g_4abdPXFWcztZsCayzFWOK180ZZZgE6PTaIcj7DWCoqHIYO8Z3PIeiyWIrGLJPKSH7tvhj9w5cOVwheSxiWam557ogi2T4UYSOzsVBt7hqMfisJpc9tiaNRPRn0B4M4ZBCauVE-bVczb2rz1ohNDG11bVKABkzfzJ7BXFgkXxCzOwH4Awi8yUNKU2sWdHCc6s8UWWciAPOkpS3mK7f9-rQvIPx_C2p4uJBWfyVG4qxo-LIkL9RGVkKeGftZemSImf29embtSVHe8nojFAo7vfKaDxXOQRQGAr7shd0k/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-balance>. Not all the finance extensions are registered in the EPP Extension Registry, that would have helped identify the overlap and the need for consolidation earlier. I don’t believe we should exclude any of the supported forms of extensibility defined in RFC 5730 from registration in the EPP Extension Registry. 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 3/5/26, 9:12 AM, "Thomas Corte" <[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 Mario, On 05.03.26 14:55, Mario Loffredo wrote: > [ML] I never said that. I simply emphasized that the implementation effort > required by EoH itself is > low because managing TCP sockets is more complex than managing HTTP requests > and sessions, > especially since several libraries in different languages support HTTP > programming. > When the .it registry planned to migrate from the old asynchronous management > system to the > synchronous EPP-based version, it decided that, for the reasons outlined > above, it was much more > advantageous for most Italian registrars registering .it domains to implement > EPP over HTTP rather > than TCP. I'd assume the ones who had already implemented EoT for some gTLDs at that point were *not* happy about that. > [ML] There's a middle ground between little or 0% and 100%. > Since RFC5730 allows EPP to be implemented on different transports, I think > it's natural to expect > that different transport layer mappings can be used. > Otherwise, it would be like saying that EPP is inextensible and unchangeable > from this perspective. > Therefore, RPP also has little reason to exist, because EPP and RPP fulfill > the same requirements > but in different ways. > EoH aims to take advantage of HTTP as a transport, minimizing the > implementation effort required by > registries planning to migrate their services to the cloud. And yet, both RPP and EoH cause more headaches for *registars*, as they'll have to deal with more diversity regarding registry connectivity (as if there weren't enough bells and whistles in EPP already). The classic quote by Tanenbaum comes to mind: "The nice thing about standards is that you have so many to choose from." As such, and this is an attempt to get back on topic, I personally wouldn't regards new transports as EPP "extensions" per se, as they don't "extend" the functionality of EPP in the least. Best regards, Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Diplom-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: [email protected] <mailto:[email protected]> Software-Entwicklung E-Mail: [email protected] <mailto:[email protected]> Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2024 _______________________________________________ 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]
