Jasdip, Leveraging more HTTP features at the transport layer doesn’t change DoH as tunneling DNS packets over HTTP. The same goes for being stateful or stateless, where in creating a transport for an existing application protocol you must follow the rules of the application protocol. EPP is a stateful application protocol and DNS is a stateless application protocol, which is a fundamental dependency for defining a compliant transport. There is nothing RESTful about DoH and the DNS packets are encoded within the HTTP requests and responses. Below are the similarities between the DoH and EoH:
1. Both leverage the HTTP GET and POST methods to push application protocol packets over HTTP 2. Both use the same server URL independent of the target resource of the query / request. DoH adds the “dns” query parameter to encode the DNS packet in a HTTP GET, since the HTTP GET can’t have a message body. 3. Both don’t map application protocol result codes to HTTP response codes, which means that the transport protocol is independent of the application protocol. The change in the HTTP response codes is based on the ability to establish a connection and pass the application protocol packet. Use of HTTP as a transport should be covered with a sibling BCP to BCP 56 since it’s clear that DoH is doing exactly the same thing as EoH for the respective application protocol. 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: Wednesday, March 11, 2026 at 1:14 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review 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. I think this from RFC 8484 sums it well vis-a-vis BCP 56: "The described approach is more than a tunnel over HTTP. It establishes default media formatting types for requests and responses but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases. In addition to this media type negotiation, it aligns itself with HTTP features such as caching, redirection, proxying, authentication, and compression.” It also helps that DNS is inherently a stateless protocol, unlike EPP. Jasdip From: Gould, James <[email protected]> Date: Wednesday, March 11, 2026 at 12:32 PM To: Jasdip Singh <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review Jasdip, Please explain how DoH differs from EoH other than DoH being stateless based on the DNS application protocol being stateless. DoH requires the server to support both HTTP GET and POST for encoded DNS packets. DoH returns the HTTP 200 independent of the DNS response code. DoH uses HTTP as a pure transport with no RESTful elements. As stated previously, I don’t see any non-conformance of the normative language in BCP 56 of either DoH or EoH. It’s unfair to EoH to apply different rules than what was is in DoH, such as the use of the HTTP CONNECT method or mapping HTTP methods to the EPP command types in what I referred to as EPP over REST (EoR). DoH pushes DNS packets over HTTP just like what is defined for EPP in EoH. I see an opportunity in the IETF to define a BCP for the use of HTTP as a transport protocol of existing application protocols that is a sibling to BCP 56 for defining application protocol / APIs. Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1XWCPypJP4bPb1m7UvzlCz9fYq9H8TDo14TORTjBzxd55VyRTiSvIxP2rLDxnUMPwIO7Us6Ku_W70BMQ4VaWsGa4BKu8WBOcgA7r0pXK-K2bNKSpHbxvEsuo6OMCCRgvAcJs_JIlvLoTo1VjbN0xaQMd2-dR08ECLlig2OEx5zBGH43VYxskZp4XYFPko0vWdgqOdUme3tnSNG0JDZ1UrVSRQRcIECcin0Pl8Hq-oER7VzWXEqP7qbtbHstJLz5lUk9dBk8x-fTQ368dtNsF0TCmLjXblpjQvd4iOq-ETMVA/http%3A%2F%2Fverisigninc.com%2F> From: Jasdip Singh <[email protected]> Date: Wednesday, March 11, 2026 at 11:55 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review 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, From: Gould, James <[email protected]> Date: Tuesday, March 10, 2026 at 4:35 PM To: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review ... I would be cautious about using DNS as an example for "modernizing" EPP. DNS is fundamentally a stateless protocol and therefore maps much more naturally onto HTTP-based transports. JG-DoH was brought up since it matches the intent in defining an HTTP transport for an existing application protocol. DoH requires the server to support both the GET and POST HTTP methods for passing the encoded DNS query packets and returning the DNS query responses. HTTP is used as a pure transport with DoH and with EoH. MW: yes, but the upper layer protocol (DNS) is a fundamentally different protocol, and due to its stateless nature more suitable for running over HTTP, you cannot use DoH as argument for EoH. JG2-DoH was simply brought up to point to another example of an existing application protocol that has defined an HTTP transport, which is not REST and is out-of-scope for BCP 56. [JS] That would be unfair to DoH. :) AFAICT, DoH took every care to be BCP 56 compliant. Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
