diff --git a/README.md b/README.md
index 723d482..52c31f4 100644
--- a/README.md
+++ b/README.md
@@ -319,19 +319,19 @@ like `xdotool`. It provides context and device negotiation between the
 server and the client - the latter must be able to adjust to limitations the
 server imposes.
 
-The current implemtation of the protocol does not allow for a `libei` client
-to send all requests in bulk and exit. The decision on whether to accept a
-device is ultimately made by the caller implementation and
-non-deterministic. For **libei** to support a batch request, *someone* would
-have to wait. It cannot be the server as the exact requirements are unknown: do
-we pause processing on the client altogether? We may miss a disconnect
-event? Do we pause processing for one device only? But then we may be
-re-ordering input events and cause havoc.
+The current implementation of the protocol does not allow for a `libei` client
+to connect, send all requests in bulk and exit. The decision on which devices
+are available is made by the EIS implementation and that requires the `libei`
+client to wait until such devices are available. On a technical level the
+protocol is object-oriented and requests cannot be sent until the respective
+device object is available.
 
-It could be `libei` itself to implement these event queues but this too can
-mess with the input order. And implementing an event queue is not hard, so
-this issue is punted to the caller instead. Xwayland in its current
-implementation already does this.
+The duration until devices become available is non-deterministic, and so is
+what types of devices are available to a client. For **libei** to support a
+connect-send-exit approach, it would still require the client process to stay
+alive until device negotiation is complete within libei and all events have
+been sent. And since the client process must stay alive, we might as well
+have the device negotiation handled in the caller.
 
 ### uinput vs libei