Maarten, We've discussed the applicability of EPP over HTTP prior to its adoption as a working group document. EoH as defined in draft-ietf-regext-epp-https does work and is completely pluggable with the other EPP transports (EoT and EoQ in draft-ietf-regext-epp-quic). EoH has been implemented in Production in various registry systems using different approaches, and draft-ietf-regext-epp-https will define a standard approach for registries that choose to support it for their customers. EPP envisioned the ability to add support for many transports, with the first being EPP over TCP (EoT) in RFC 5734 defined over 20 years ago. DNS has been modernized with DoH and DoQ, and the same should be the case to modernize EPP.
Please review draft-ietf-regext-epp-https for any concrete technical issues. 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/9/26, 12:11 PM, "Mario Loffredo" <[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 Marteen, stateful interactions over HTTP are not only possible but well defined. HTTP explicitly supports maintaining application state through standardized mechanisms such as cookies (RFC6265). The ongoing work on RFC6265bis does not suggest that this model is going away anytime soon. In addition, the EoH work has already incorporated feedback from the authors of RFC6265bis. More importantly, EPP over HTTP has already been deployed in production for nearly two decades by some registries. In practice, this approach has proven to be clean, maintainable, and far from the brittle solution suggested in the previous message. Could you provide concrete operational scenarios that support the claim that layering EPP over HTTP would inevitably lead to fragile implementations? On the other hand, there are practical scenarios — for example high-throughput situations such as drop time — where authenticating every request using HTTP Basic authentication may be less efficient than leveraging a previously negotiated shared secret such as a session identifier. Finally, from a deployment perspective, EPP over HTTP appears significantly less disruptive for existing registries and registrars than introducing an entirely new protocol stack such as RPP. If authentication were to move toward OAuth2/JWT token management rather than HTTP Basic authentication, the operational and implementation gap would likely become even larger. Best, Mario Il 09/03/2026 15:06, Maarten Wullink ha scritto: > Hi, > > I agree with much of the feedback provided by the OP (Mark), standardizing > EPP over HTTP will force implementers to effectively hack a stateful protocol > onto a stateless transport. EPP relies on persistent sessions for login, > command ordering, and session lifecycle. HTTP provides none of these > guarantees. Attempting to layer state on top of it will inevitably lead to > (brittle) solutions that require additional mechanisms, session management, > cookies, routing, etc. In order to emulate what the current EPP TCP transport > already provides. > > In practice, this is unlikely to result in a clean, maintainable solution. It > will almost certainly spawn further WG documents to try to standardize > session management, login flows, and command ordering and more potential > issues, increasing the complexity and scope of EPP and the workload for this > WG. > > For these reasons, I think the WG should carefully consider whether EPP over > HTTP is a good path forward. > > > - > Maarten > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://secure-web.cisco.com/1-cHH70U6acg4O-e9kqG-djaFtD_VL0UUZzI6svF7iCkfa2veb8RKeYGuAA-Ji4Fv2p9oleOIcwICtNg8gkpKYDXlExt18Y7r3kjzSziSe9sXkpMwP-NVRL1bZZ684Sj9QQkFEFCdz9F4Vi6p1O2I2IAzTUimGzXn59Ds0EtQ1KI9o03nkDwQmIHVKKITdTzirCEQfTGSr0ijIgWgjeidLBgYlENfwquJIjMXkbdJyaJMzQ6-kMYiJ9wEXdXMQ6VN2d6-vgDdPePOT5e7uEI-2gzrPTFvpaLPUAtQI2LEqZE/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo <http://secure-web.cisco.com/1-cHH70U6acg4O-e9kqG-djaFtD_VL0UUZzI6svF7iCkfa2veb8RKeYGuAA-Ji4Fv2p9oleOIcwICtNg8gkpKYDXlExt18Y7r3kjzSziSe9sXkpMwP-NVRL1bZZ684Sj9QQkFEFCdz9F4Vi6p1O2I2IAzTUimGzXn59Ds0EtQ1KI9o03nkDwQmIHVKKITdTzirCEQfTGSr0ijIgWgjeidLBgYlENfwquJIjMXkbdJyaJMzQ6-kMYiJ9wEXdXMQ6VN2d6-vgDdPePOT5e7uEI-2gzrPTFvpaLPUAtQI2LEqZE/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> _______________________________________________ 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]
