Hi, 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.
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? Thanks, Jasdip 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 Jasdip, 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. Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> 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 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. 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]
