DoH being BCP56 compliant (or not) is tangential to this EoH discussion. It may be an interesting academic exercise, but in the end is not relevant. DoH solves significant security issues for millions of Internet users. EoH provides nothing significant over EoT. From the perspective of violating (or not) BCP56, EoH is not in the same relevant space as DoH.
Convincing the IETF that EoH needs to violate BCP56 is in the same realm as trying to convince the IETF that TLS 1.0 is a requirement. It can be done, but there needs to be a very, very good reason to do so. IMHO, such a reason has never been given. -andy, as an individual On 19-03-2026 6:21 AM, Jasdip Singh wrote:
Hi Mario, Thanks for engaging in this discussion. Your rationale below seems reasonable. Per the “Proposed Next Steps” slide from your presentation, it would be good to expound on this architectural choice in the draft, as well as why BCP 56 is not applicable. As to EoH co-existing with RPP, defer to the WG decision and the IESG. Cheers, Jasdip *From: *Mario Loffredo <[email protected]> *Date: *Wednesday, March 18, 2026 at 8:01 AM *To: *[email protected] <[email protected]> *Subject: *[regext] Re: POST use in EoH versus DoH EoH sounds like an HTTP anti-pattern. :) EoH wants to distance from BCP 56 but still use HTTP. It wants to use HTTP gateways but without any of the HTTP benefits BCP 56 would have afforded. [ML] BCP56 is a set of recommendations for HTTP native protocols, i.e., protocols that use HTTP as the application model. EPP has its own model, described in RFC5730. DoH did not redesign DNS to conform to the HTTP application model; it simply prepared DNS to be implemented over HTTPS, leveraging some HTTP features. Like DoH, EoH follows the same approach. It uses HTTP as the carrier for application protocol messages, leveraging some HTTP features while preserving the EPP model and logic. Regarding the use of CONNECT, I already highlighted in my presentation the reasons why it cannot be considered a viable solution. Essentially, it makes no sense to implement a L7 application protocol that would have the same limitations as a L4 application protocol. EoH was designed to overcome these limitations and make it suitable for cloud environments. From what-not-to-do perspective, why do EoH as a standard in the short-term when RPP promises to adhere to BCP 56 and become a contender to EPP in the long-term? [ML] First, I would argue that EoH is the fastest way to migrate EPP to L7. EoH preserves the EPP logic (i.e., messages, result codes, extensions). Compared to EoT, what changes is the transporter. Therefore, the effort required to implement EoH to those accustomed to working with EoT, in order to run EPP in the cloud, is minimal (see Verisign's implementation). I'd also add that stateless isn't necessarily good, just as stateful isn't necessarily bad. There are practical scenarios where performing authentication and EPP negotiation on every request is highly inefficient. I believe this opinion is shared by other members of the working group. Otherwise, I'd be hard-pressed to understand why we introduced sessions in RDAP. *From: *Gould, James <[email protected]> *Date: *Tuesday, March 17, 2026 at 7:08 PM *To: *Jasdip Singh <[email protected]>, [email protected] <[email protected]> *Subject: *Re: Re: [regext] Re: POST use in EoH versus DoH EoH is posting packets and the semantics of the application protocol packets are not applicable, which is what defining a transport protocol is. BCP56 is associated with application protocols, and I don’t believe it is associated with transport protocols. DoH defines a transport protocol just like EoH. HTTP CONNECT doesn’t meet the intent of EoH to make it simple for registries to deploy to the public Cloud leveraging existing HTTP gateways. There is no need to create a custom Gateway with EoH. Do the Cloud HTTP gateways support HTTP CONNECT and enable EoH application servers to get routed the EoH packets? Your “What Makes for a Successful Protocol” applies here with “ease of implementation and interoperability”, where EoH as defined will certainly work as designed in a Cloud environment with no technical issues. Please explain what will fail with EoH as defined. *From: *Jasdip Singh <[email protected]> *Date: *Tuesday, March 17, 2026 at 6:49 PM *To: *James Gould <[email protected]>, "[email protected]" <[email protected]> *Subject: *[EXTERNAL] Re: Re: [regext] Re: POST use in EoH versus DoH James, Hope we can agree that EoH violates BCP 56 by overloading POST semantics for updates and deletions in EPP. When EoH overloads POST, it is essentially telling HTTP to ignore semantics and just “tunnel” such a request, irrespective of if it were meant for an update or a deletion. This tunneling behavior seems what HTTP CONNECT would offer. Wonder why HTTP CONNECT is not considered appropriate for EoH if HTTP is to ignore message semantics anyway. Jasdip *From: *Gould, James <[email protected]> *Date: *Tuesday, March 17, 2026 at 5:19 PM *To: *Jasdip Singh <[email protected]>, [email protected] <[email protected]> *Subject: *Re: Re: [regext] Re: POST use in EoH versus DoH In reviewing RFC 8484, “more than a tunnel over HTTP” means that more features of HTTP are being used, but fundamentally it’s a superset of tunneling over HTTP. The name of RFC 8484 is “DNS Query over HTTPS (DoH)”, which says it all. *From: *Jasdip Singh <[email protected]> *Date: *Tuesday, March 17, 2026 at 4:32 PM *To: *James Gould <[email protected]>, "[email protected]" <[email protected]> *Subject: *[EXTERNAL] Re: [regext] Re: POST use in EoH versus DoH No, DoH adheres to BCP 56 and uses HTTP GET and POST methods /appropriately/ to transfer “application/dns-message” resource representations. As RFC 8484 says: "more than a tunnel over HTTP”. IMHO, this distinction with a traditional transport protocol is important. Jasdip *From: *Gould, James <[email protected]> *Date: *Tuesday, March 17, 2026 at 4:12 PM *To: *Jasdip Singh <[email protected]>, [email protected] <[email protected]> *Subject: *[regext] Re: POST use in EoH versus DoH You seem to miss that DoH also pushes packets just like EoH independent of the application protocol actions needed, which is using HTTP as a transport protocol. Having more application protocol actions in EPP than DNS, leveraging more HTTP features (e.g., stateless, caching) in DoH doesn’t change that DoH and EoH are doing the same thing in defining HTTP as a transport protocol. *From: *Jasdip Singh <[email protected]> *Date: *Tuesday, March 17, 2026 at 3:48 PM *To: *James Gould <[email protected]>, "[email protected]" <[email protected]> *Subject: *[EXTERNAL] Re: [regext] Re: POST use in EoH versus DoH It is important to compare EoH with DoH since they are accomplishing the same task of defining a HTTP transport protocol for an existing application protocol with no transparency of the application protocol at the transport protocol layer. [JS2] Re: the "HTTP transport protocol” and "no transparency of the application protocol at the transport protocol layer” phrases. Just like the POST method conflation in EoH, I think there is another fundamental distinction to keep in mind here. HTTP is NOT a traditional transport protocol like TCP, UDP, or QUIC. It is rather a /representational state transfer/ protocol for a resource at the application layer. A transport protocol does not care about the semantics of data (just an opaque pipe) whereas a (hypertext) transfer protocol like HTTP does through appropriate methods (GET, POST, PUT, DELETE, etc.) operated on a resource and its representation(s). That’s why adherence to BCP 56 should matter for EoH, IMHO. BTW, if "no transparency of the application protocol at the transport protocol layer” is actually desired from HTTP vis-a-vis EPP, that’s where HTTP CONNECT (tunnel) should come handy. The GET and the POST is used to push packets in both DoH and EoH independent of the application protocol scenarios. In the meeting with Mark Nottingham, he had a concern related to use of HTTP as a general transport protocol and discussed this with the editors of DoH. He looks receptive to support the EoH case as well and I provided the latest draft for his review. I like “…ease of implementation and interoperability” from What Makes for a Successful Protocol?, which means to me ensuring proper layering and pluggability of the EPP transport. I have demonstrated this with implementing true pluggability of EoT, EoH and EoQ in the Verisign EPP SDK with full support for session pooling on the client side and running all the implemented EPP extension tests on all three transports. [JS2] Unlike EoH, EoQ seems closer to actually using a transport protocol in QUIC. *From: *Jasdip Singh <[email protected]> *Date: *Tuesday, March 17, 2026 at 1:54 PM *To: *regext <[email protected]> *Subject: *[EXTERNAL] [regext] POST use in EoH versus DoH Just wanted to follow up on one point from yesterday’s EoH presentation in REGEXT. When comparing EoH with DoH, it was noted that both use GET and POST. But there is one important distinction when it comes to BCP 56. DoH correctly falls back to POST if an equivalent GET query gets too large, per BCP 56 (4th para in [1]). In contrast, EoH seems to overload the POST use for PUT and DELETE scenarios, violating BCP 56. IMHO, it does not help to compare EoH with DoH. Guess that’s why the HTTPDIR review [2] recommended HTTP CONNECT instead to avoid the BCP 56 violation. Not questioning that EoH is a sincere effort to leverage HTTP and already in use, but the BCP 56 violation should give us a pause to re-consider if EoH is a good technical design per What Makes for a Successful Protocol? [3]. [1] _https://www.rfc-editor.org/rfc/rfc9205.html#name-get <https://secure-web.cisco.com/1_YqKh8katIrdu-7vKhycxNIRlT2WwW4M4D2pMqGJLhnSgB0rZSglg-ZPVEz_7WnpJwDzribWjy96wm5oXkB5dQQ4nPQBKh0PkRVUaRQB8YC3oLheh9XHX_CzcXUmPKeg8jf7s61Bo_PspIvlqwKHwA2_rQdaHKKLo9H1CaQAugZX71MUFq2nfjbrnsHV-SxfTz5e9d477zGgmK1xOzuXVlCLmESLkDCsDOvrqo1hcOZBVrQ8OaIh3i8C9tEWVst8QQVP0VNUJlTTaZDF5r3xFpLrlHMhRjmEapPP6jQvYbWU_kYCzJFHMvQl_nSUbeet/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9205.html%23name-get>_ [2] _https://datatracker.ietf.org/doc/review-ietf-regext-epp-https-02-httpdir-early-nottingham-2025-11-30/ <https://secure-web.cisco.com/1ZeL8sMcPccjhrVAUly5gvcZ4zpt4k1Yn6AAefBwOeIgeSEO_QlRJ-6Gy6BCKF745crLmYHvZNYMpxR08ABqDBFOjiUBZ92Mqs0UFj44gcG1eMfHQwG6Xw6_KCasC7C9WNKxDLFmXkO9R42igrMD0bDWfxFRkBiCBxMfKM-xRQ8usyJT72d6TEHj_uYlvcLleYqUKIznaNGYO7YL_TGjmOzvHs5ayN655P5bZ4zGfcdwO6KFrZV7WD5-t49DscnlJhhZeGbt71A-ycCWm0R1GxxXBfKpqKxfe0p17l5732DA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-regext-epp-https-02-httpdir-early-nottingham-2025-11-30%2F>_ [3] _https://www.rfc-editor.org/rfc/rfc5218.html#page-11 <https://secure-web.cisco.com/1TcCqSXFh2rdeHjtrdfzMiRMcp6cVfpbwE64ZFbQCWmZjPHHgiSJnrLha9Mo_c6W8RUBJoLXjKLJTbp7BBOVqSQtK2Uofro0XnxDTyDvjnXZpPFhnkPPO28Tsq7kJ2jeGJk3tdjH31_eHjkmSY92f8uA5tnjUIVXC2ufUG4CVsSF0ZwIf31xTgy3S2wAJcU4scYXGVwepzoXsJNyk4d97TC_K9NKy3GwqSlUaPEGgITLqgbWJysRrqpRi9cAhmi_tiaU6ICd_-sC1crbKytIFQeHdUz7MeFtG7XL_hve7UQdiVcvIE-Kzvu3c-smLsJfw/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5218.html%23page-11>_ _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
