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. 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. 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. 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. 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. Each of these raises new questions about how they interact with EPP semantics and whether they should be specified, restricted, or ignored. This can easily lead to the working group spending significant effort defining the boundaries of HTTP usage rather than focusing on protocol extensions. 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. 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. 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. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
