Martin, We see a mix of non-pipelining and pipelining clients in EPP. By requiring the servers to process the commands in the order that are sent on an EPP connection, the clients are in control of the order and can design to it. Pipelining clients can leverage the client transaction identifier as a form of an Asynchronous Completion Token (ACT), non-pipelining clients can take the simple approach of waiting of the response prior to sending the next command, and then there is the ability to use an extension to define composite commands and commands that perform asynchronous processing of a set of commands. This all comes down to have the building block of ordered processing of the commands in the server.
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/3/26, 6:00 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. Hi Scott, On Tue, Feb 3, 2026, at 23:10, Hollenbeck, Scott wrote: > If those two commands aren't processed in that specified order, the > "remove name server C" command will fail if it gets processed first > because C isn't part of the existing set. In HTTP-land, we have the same issue often. The way this is managed is at the application layer. You don't pipeline those requests and rely on pipeline ordering. Instead, you issue the first request, wait for a reply, then issue the second. (Or, in this case, you don't issue either request, because the end result should be net nothing.) Obviously, pipelining can make some operations more latency efficient, but I get the distinct sense that EPP isn't really optimized for latency. Robustness seems to be far more important. Maybe it is the specifics of this example that are in the way. Are there more generally cases where one command sets up state that subsequent commands rely on? Like the creation of a name server that you then assume is present in subsequent commands? And you really need those commands to be pipelined, if not for performance, at least because this is common practice in existing implementations. If that is the case, having multiple commands per stream is (very) well justified. That would be the justification I use for the design, to the point of saying that, rather than saying "commands must be ordered" without explanation. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
