Martin, My feedback is embedded below prefixed with "JG2-".
Thanks, -- 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 2/2/26, 7:27 PM, "Martin Thomson" <[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. 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. JG2-Maybe Lucas can weigh in on this since the versioning was added based on his recommendation. I believe it's fine with or without the versioning since I don't anticipate much material change at the transport layer. > 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? JG2-I see that Scott Hollenbeck, who is authoritative for this, has replied with the reason. The reason I have is that an EPP transport, like EoQ, must comply with the Transport Mapping Considerations defined in section 2.1 of RFC 5730. > 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. JG2-I believe that the existing EoQ approach balances the KISS principle with the performance advantages of QUIC in the ability to reuse the TLS established for the QUIC connection in the QUIC streams, which corresponds to the EoQ connections. > "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? JG2-The timer applies to the stream and not the connection since the connection can have many streams. I implemented this with session pools with a configurable idle timeout that sends the EPP hello command on the EoQ connection (QUIC stream) to keep the EoQ connection alive. > 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. JG2-EoQ is defining a transport and not the application protocol, which is defined in RFC 5730. There is abstraction of the transport for EPP, where the transport much comply with section 2.1 of RFC 5730. An EPP connection is started by the client without sending any XML data and the server returns the EPP greeting, after that the command and response process starts, including the passing of the EPP login to establish an authenticated EPP session. When a QUIC stream is created on the client side, we must trigger an action on the server side to return the EPP greeting, which is the function of the transport-specific EoQ Connection Start Packet. The transport must play by the rules defined by the application protocol. > 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). JG2-I believe it is relevant to demonstrate that the underlying transport protocol does support packet framing, but I agree that the inclusion of the EoQ packet framing could be added to fully comply with this. I'll add a statement associated with the EoQ packet framing, which would be in line with how EoT in RFC 5734 defines it. * 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). JG2-Good catch, draft-ietf-regext-epp-quic doesn't cover the pipeline-specific requirements. This will be addressed. 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. JG2-I believe Scott Hollenbeck addressed the question around ordering. In pipelining, where many commands are sent in bulk without waiting for the response, this requirement is meant for the server to process one command at a time and send the response for each command to the output stream and not implement some kind of grouping logic (e.g., the server grabs 5 commands at a time and distributes them for parallel processing). That is my interpretation of "processed independent of each other", where the order is up to the client and not the server. JG2-I don't consider RFC 5730 to contain any backage, since it has been relied upon to serve the domain name industry for over 20 years. We need to ensure to meet the requirements of the mature EPP application protocol and provide for easy pluggability of a new transport like QUIC, which I demonstrated in the Verisign EPP SDK available at https://www.verisign.com/resources/registrar-resources/epp-sdk/. The Verisign EPP SDK demonstrates running all EPP and a large set of EPP extensions on top of EoT in RFC 5734, EoQ in draft-ietf-regext-epp-quic, and EoH in draft-ietf-regext-epp-https with no change required from the application layer.
