Maarten, I provide my responses to your feedback embedded below, prefixed with "JG-".
-- JG 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/> On 3/10/26, 4:23 AM, "Maarten Wullink" <[email protected] <mailto:[email protected]>> wrote: 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 Jim, Mario I do not dispute that stateful interactions over HTTP are possible. Mechanisms such as cookies (RFC6265) clearly allow applications layered on HTTP to maintain state. However, the existence of such mechanisms does not necessarily make them an appropriate fit for every protocol. The question here is not whether HTTP can support state, but whether introducing HTTP-layer session semantics into EPP leads to a clean and well-defined protocol architecture. JG-This is the purpose of draft-ietf-regext-epp-https in defining a standard mechanism for the stateful EPP to ride on top of HTTP, which must leverage the HTTP-layer session semantics. Let us know whether you see any technical issues in draft-ietf-regext-epp-https. In RFC 5730 there is a clear separation between: the EPP protocol itself, which is stateful and defines its own session semantics (login, logout, command sequencing), and the transport layer, which RFC 5734 currently specifies as TCP with TLS. JG-Correct, the EoH connection leverages the HTTP session to match what exists today with the TCP connection in RFC 5734. Establishing the EoH session is based on successfully executing the EPP <login> command, as is the case for EoT. If EPP were mapped directly onto HTTP while preserving EPP’s existing session model, the result would effectively introduce two overlapping session layers: - EPP session state (login/logout, command sequencing) - HTTP session state (cookies or similar mechanisms) At that point the transport is no longer a simple framing mechanism, but begins to influence protocol semantics. That tends to complicate both implementations and interoperability, because state transitions must now be coordinated across two layers. JG-I don't see the complexity here since the HTTP-layer is handling the establishment of an encrypted stateful connection to the server via the HTTP session. The EPP application protocol is not impacted by the underlying transport layer, which I've demonstrated in the Verisign EPP SDK by running all the EPP tests via configuration of the transports (EoT, EoH, and EoQ). With EPP over TCP, the behavior is straightforward. If the client stops sending requests, the TCP connection closes, and the EPP session dies immediately. EPP over HTTP is messier. The session now depends on the lifetime of the HTTP connection or session, which means the server must keep EPP session state alive somewhere. This can result in stale or abandoned session data lingering for a long time, increasing complexity and resource usage, and making a clean, predictable session model much harder to maintain. JG-There is the concept of an idle timeout in implements of EoT, which applies to EoH as well to keep the connection (EoT or EoH) alive. The EoH connection pool in the Verisign EPP SDK transparently handles the keep-alive via the EPP <hello> and handles closing and refreshing the EoH connections. There is also a practical scope concern for the working group. If HTTP is introduced as a transport, even in a minimal form, there will inevitably be pressure from implementers to make use of additional HTTP features. for example cookies, caching semantics, additonal headers, additional authentication schemes, or other aspects of the HTTP ecosystem. JG-I'm not sure what pressure you're referring to. If EoH becomes an RFC there will be a standard approach defined for implementing EPP over HTTPS. There have been numerous implementations of EPP over HTTPS using different approach that would be consolidated down to one approach as an option of registries to deploy if desired. Each of these raises new questions about how they interact with EPP semantics and whether they should be specified, restricted, or ignored. JG-There needs to be no impact to the EPP semantics in defining an EPP transport. If there are required changes to EPP semantics, then I don't believe the considerations in Section 2.1 of RFC 5730 would be met. This can easily lead to the working group spending significant effort defining the boundaries of HTTP usage rather than focusing on protocol extensions. JG-Please review draft-ietf-regext-epp-https and identify any concrete issues of the HTTP usage that poses a risk that we can directly address. Production deployments demonstrating that EPP over HTTP can work are valuable input. However, they do not necessarily resolve the design question of whether the resulting architecture is the clearest or most robust model to standardize. JG-RPP represents the cleanest approach for the use of HTTP, since it will be stateless, but EPP should have the option of use of a more modern transport to what exists today with EoT. 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. My main concern is therefore not whether EPP over HTTP can function in practice, but whether standardizing it in this form results in a transport mapping that remains consistent with the layering model established in RFC 5730. JG-What aspect would not be consistent? If an implementer has the intent to implement a new HTTP transport protocol for EPP or customize EoH, then they would not be implementing EoH as defined by the working group. Is there any normative language that you see needs to be added to draft-ietf-regext-epp-https to ensure consistency in the future? _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
