Pawel, Section 2.1 of RFC 5730, includes the normative language "The transport mapping MUST explicitly allow or prohibit pipelining.", which is related to sending commands without waiting for the response to a prior command. EoH explicitly disallows pipelining to maintain the order requirement. I believe the pipelining statement in draft-ietf-regext-epp-https should be a normative "MUST NOT". We should not attempt to create order on the server side, which would greatly increase the complexity.
-- 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/17/26, 1:10 PM, "Pawel Kowalik" <[email protected] <mailto:[email protected]>> wrote: Hi Mario, On 17.03.26 17:49, Mario Loffredo wrote: > > [ML] EoH draft specifies that the cookie contains the session > Identifier, not the entire session. > > Regarding the order, James, in reply to Maarten, has already proposed > a solution to your question. > > In any case, in normal operation, a client sends a new request after > checking the response of the previous one, stating with the EPP Login > and ending with the EPP Logout. > Are you referring to this proposed text "Command MUST be processed independently and in the same order as received on the EoH connection.". The issue here is that EoH connection does not guarantee any particular order. Each EoH request, even if sharing the same session (cookie), can arrive to the server in different order than it was sent by the client. When the cloud deployment is considered and multiple instances process EoH request it is not even obvious to tell in which order the requests have been received unless sticky sessions are applied and all requests land at the same server instance. The only answer EoH hast right now is telling the client that they MUST NOT send new request before receiving a response. This is weak and I think this does not fulfil the requirements set out in 5730. A stronger approach would be to enforce it by binding previous response and the next request on EoH level, for example by adding a message counter or last message ID to the response cookie, so that the server can reject messages coming out of order or if any intermediate message was lost. Kind Regards, Pawel _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
