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]
