Hi Jasdip,
please find my comments inline.
Il 18/03/2026 03:49, Jasdip Singh ha scritto:
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.
[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.
Best,
Mario
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 [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://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
