QUIC Polling Design: Fix nitsfeature/quic-server

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23455)

1 files changed, 7 insertions, 7 deletions

diff --git a/doc/designs/quic-design/server/quic-polling.md b/doc/designs/quic-design/server/quic-polling.md
index 02d232e89c..68b2c8a89d 100644
--- a/doc/designs/quic-design/server/quic-polling.md
+++ b/doc/designs/quic-design/server/quic-polling.md
@@ -254,7 +254,7 @@ We define the following event types:
   terminating (Terminated state).
 
 - **IC (Incoming Connection):** There is at least one incoming connection
-  incoming and available to be popped using `SSL_accept_connection()`.
+  available to be popped using `SSL_accept_connection()`.
 
 - **ISB (Incoming Stream — Bidirectional):** There is at least one
   bidirectional stream incoming and available to be popped using
@@ -352,7 +352,7 @@ From our discussion below we derive some general principles:
 
 /* Read/write and associated exception event types. */
 #define SSL_POLL_EVENT_RE           (SSL_POLL_EVENT_R  | SSL_POLL_EVENT_ER)
-#define SSL_POLL_EVENT_WE           (SSL_POLL_EVENT_R  | SSL_POLL_EVENT_ER)
+#define SSL_POLL_EVENT_WE           (SSL_POLL_EVENT_W  | SSL_POLL_EVENT_EW)
 #define SSL_POLL_EVENT_RWE          (SSL_POLL_EVENT_RE | SSL_POLL_EVENT_WE)
 
 /* All exception event types. */
@@ -389,7 +389,7 @@ A. The event type is raised on a QLSO only. This may be revisited in future
 **Q. Why does this event type need to be distinct from `EC`?**
 
 A. An application which is not immediately concerned by the failure of an
-indiivdual connection likely still needs to be notified if an entire port fails.
+individual connection likely still needs to be notified if an entire port fails.
 
 #### `EC`, `ECD`: Exception on Connection (/Drained)
 
@@ -516,7 +516,7 @@ only care about the possibility of a stream reset.
 **Q. Should applications be able to listen on `R` but not `ER`?**
 
 A. This would enable an application to listen for more application data but not
-care about stream resets. This can be permitted for now even if it raises osme
+care about stream resets. This can be permitted for now even if it raises some
 questions about the robustness of such applications.
 
 **Q. How will the future reliable stream resets extension be handled?**
@@ -601,7 +601,7 @@ there is no particular harm in doing so. Current decision: do not report it.
 **Q. What if the send part was reset locally and then we also received a
 `STOP_SENDING` frame for it?**
 
-A. If the local application reset a stream locally, it knows about this fact
+A. If the local application has reset a stream locally, it knows about this fact
 therefore there is no need to raise `EW`. The local reset takes precedence.
 
 **Q. Should this be reported if shutdown has commenced?**
@@ -641,7 +641,7 @@ yet to be popped via `SSL_accept_stream()`.
 A. It is raised on anything that would cause `SSL_accept_stream()` to return a
 stream. This could include a stream which was created by being reset.
 
-**Q. What happens if this event is raised on a QSSO or QLSO?**
+**Q. What happens if this event is enabled on a QSSO or QLSO?**
 
 A. The event is never raised.
 
@@ -676,7 +676,7 @@ A. The event is never raised.
 
 **Q. Can this event be raised before a connection has been established?**
 
-A. Potentially in future, on the client side only, if 0-RTT Is in use and we
+A. Potentially in future, on the client side only, if 0-RTT is in use and we
 have a cached 0-RTT session including flow control budgets which establish we
 have room to write more data for 0-RTT.