Klaus, You are correct that there is no order enforced on the server-side when the commands are spread across multiple EPP connections, so it’s a decision for the client. The EoQ connection that is associated with an individual QUIC stream follows the same semantics of an EPP connection on top of TCP, where the server MUST preserve command order. This enables pluggability of QUIC as a transport for EPP, since a client can choose whether to send commands over QUIC via EoQ or over TCP via EoT, where the command semantics are the same meaning order is preserved. Pluggability of transport is the benefit of ensuring that the requirements in section 2.1 of RFC 5730 are satisfied in the transport specification.
-- 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/4/26, 12:01 PM, "Klaus Malorny" <[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 all, I am following the discussion about the in-order processing a little bit and am puzzled to some extent. It is ok to me to demand in-order processing within a session, but the justification is in my humble opinion not convincing. The use of multiple TCP connections to the registry server for a single registrar and distributing the requests among them is common practice. There are actually no assertions regarding the execution order among multiple connections. In respect to the transport over QUIC draft, there seem to be neither any order execution guarantees between multiple QUIC streams. So developers on the client side have to take this into account anyway. In addition, I personally regard the submission of multiple commands depending on each other without waiting for the respective responses as a bad programming practice. I would not encourage such a practice protocol-wise. But others may see this differently. Assuming an existing out-of-order processing within a session, this would actually make the use of QUIC mostly superfluous. Contrary to HTTP, the traffic between client and server is not characterized by the transmission of potentially large quantities of data that cannot be interrupted and which is further complicated by limited bandwidth. EPP messages are typically small and the use of client transaction IDs would allow a reordering (which QUIC does on a stream level). So I would rather argue with the observance to the KISS principle, the principle of least astonishment, with separation of concerns (between EPP and QUIC) and/or the logical backward compatibility with EPP over TCP. Just my two cents. Regards, Klaus Malorny -- ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Geschäftsführer: Registereintrag: Dietmar Knipp, Elmar Knipp Amtsgericht Dortmund, HRB 13728 _______________________________________________ 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]
