My suggested modifications

rfc9204.md

@@ -640,7 +640,7 @@ HPACK defines string literals to begin on a byte boundary.  They begin with a
 single bit flag, denoted as 'H' in this document (indicating whether the string
 is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and
 finally Length bytes of data. When Huffman encoding is enabled, the Huffman
-table from {{Section B of RFC7541}} is used without modification, and Length
+table from {{Section B of RFC7541}} is used without modification and Length
 indicates the size of the string after encoding.
 
 This document expands the definition of string literals by permitting them to
@@ -1212,8 +1212,8 @@ attack into a linear-time attack.
 QPACK mitigates, but does not completely prevent, attacks modeled on CRIME
 ({{CRIME}}) by forcing a guess to match an entire field line rather than
 individual characters. An attacker can only learn whether a guess is correct or
-not, so it is reduced to a brute-force guess for the field values associated
-with a given field name.
+not, so the attacker is reduced to a brute-force guess for the field values
+associated with a given field name.
 
 Therefore, the viability of recovering specific field values depends on the
 entropy of values. As a result, values with high entropy are unlikely to be
@@ -1378,7 +1378,7 @@ immediately sent due to flow control is not affected by this limit.
 Implementations should limit the size of unsent data, especially on the decoder
 stream where flexibility to choose what to send is limited.  Possible responses
 to an excess of unsent data might include limiting the ability of the peer to
-open new streams, reading only from the encoder stream or closing the
+open new streams, reading only from the encoder stream, or closing the
 connection.