On Tue, Feb 3, 2026, at 09:59, Gould, James wrote: > JG-"eoq" was changed to include the versioning based on feedback from > Lucas, which is set to "eoq/0.1" and will be changed to "eoq/1.0" once > the draft passes WGLC.
During QUIC development, we named things "whatever-09" matching the draft. Then we removed the suffix. ALPN doesn't work with semantic versioning, so I'd strongly recommend you not try to embed semantic versioning-like strings in it. > JG-Yes, ordering is a requirement, based on the normative language in > the Transport Mapping Considerations section 2.1 of RFC 5730, which > states " The transport mapping MUST preserve command order.". That's a conclusion, not a reason. Is there a concrete reason? > Having to login on every stream seems unnecessary. [...] > > JG-This is to enable the QUIC stream to function equivalently to an EPP > connection, which has a very specific state machine. When a connection > is established, the EPP server returns the EPP greeting, then starts > the command and response flow with the EPP login and EPP logout > starting and stopping the EPP session. The same is possible with a different design. Let's say you login on one stream and assume that the login applies to all other streams. (You might need to distinguish that stream somehow and have just one, but that's a detail.) Someone seeking to bridge to EPP on TCP would be able to copy the login to every TCP connection that is made. Then you login once and can use streams within QUIC faster. It's OK to do as you have. It's the lazy option and being lazy is often good. I just wanted to push on it a little because you are leaving serious performance advantages on the table. > "A server SHOULD impose a limit on the amount of time required for a > client to issue a well-formed EPP command " - Is this globally, or > per-stream? > > JG-This is language reused from EoT in RFC 5734 and it’s a setting per > EoQ connection (e.g., QUIC stream). The EPP server will implement an > idle timeout, and in practice clients are recommended to keep the > connection alive using the lightweight EPP hello command. What I meant to ask is: how is this implemented? It is currently unclear to me. If I have an open stream with a completed exchange, does this timer apply to that stream? Or does it apply only once a request has started? With a setting per connection is that a timer per connection? If one stream starts on one request, then another stream finishes delivery of a different request, is that OK? Does the first stream have to complete within the configured time? > I found the definition of the connection start hard to understand. I > *think* that you are saying that the literal string "EoQ Connection > Start" is sent instead of XML. I have to ask: why? > > JG-Yes, this was something that I found had to be added to have the > stream created on the server side, since the stream is created lazily > on the server side when data is written by the client. The EPP state > machine starts with the client connection for the server to return the > EPP greeting and does not start by the client sending XML. The EoQ > Connection Start was needed to bootstrap the EoQ connection. It is a > challenge mapping the EPP terminology to the QUIC terminology to enable > QUIC to be a compliant EPP transport. Let me know if you have any > recommendations to clarify this. I don't think that this is necessary. It seems like you could reasonably not create streams on the server side until the client has something to do. In a better model (at least by my reckoning), you would only have requests and responses on streams, with login managed separately. Then the client can spin up streams for batches of requests where ordering is important, as needed, with no login exchange overhead. If you have a login on every stream, then the login would suffice to create server state. If that mattered. But then, what purpose does that server state serve if not the answering of requests? So why insist on creating it before there are requests to answer? Hence the suggestion above regarding one login per connection rather than one per stream. > Section 7 seems to describe features of QUIC, rather than features of > EoQ. Consider trimming it to those things that are important for EoQ > functioning. > > JG-Section 7 is important to match the transport requirements defined > in Transport Mapping Considerations section 2.1 of RFC 5730, so its > length is to demonstrate EoQ compliance as an EPP transport. This > follows the approach taken for TCP in RFC 5734. As a checklist, fine. But you don't need to publish anything other than things that are not trivially obvious. And some of these are not statements of how EoQ satisfies requirements, but statements of how QUIC works. Specifically: * Frame Data Units describes framing in QUIC, which is not relevant. What is relevant here is the framing you have added for individual messages (the 32-bit length). * I didn't see an answer for "The transport mapping MUST describe how an error in processing a command affects continued operation of the session." That really does seem important (Lucas mentioned stream errors, which might be involved there). FWIW, I think that RFC 5730 is not clear on the ordering thing, because it says "Commands MUST be processed independent of each other." Which isn't true if there is the potential for ordering to matter. Which is why I asked about the real reason for ordering, above. If there is no ordering dependency between commands, then a very different model - one without head-of-line blocking - is possible. My read of RFC 5730 is that it has some serious baggage and you need to think a little more carefully about what the requirements of the protocol really are, not what someone wrote once upon a time.
