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]
To unsubscribe send an email to [email protected]
