Jasdip, 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. 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. 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: 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 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. 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]. Thanks, Jasdip [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]
