Reflow

draft-ietf-quic-transport.md

@@ -2759,16 +2759,15 @@ ordered byte-stream.  Data received out of order MUST be buffered for later
 delivery, as long as it is not in violation of the receiver's flow control
 limits.
 
-An endpoint MUST NOT send data on any stream without ensuring that it
-is within the data limits set by its peer.  The cryptographic
-handshake stream, Stream 0, is exempt from the connection-level data
-limits established by MAX_DATA. Data on stream 0 other than the
-initial cryptographic handshake message is still subject to stream-level data limits and
-MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs
-to be sent in a single packet regardless of the server's flow control
-state. This rule applies even for 0-RTT handshakes where the
-remembered value of MAX_STREAM_DATA would not permit sending
-a full initial cryptographic handshake message.
+An endpoint MUST NOT send data on any stream without ensuring that it is within
+the data limits set by its peer.  The cryptographic handshake stream, Stream 0,
+is exempt from the connection-level data limits established by MAX_DATA. Data on
+stream 0 other than the initial cryptographic handshake message is still subject
+to stream-level data limits and MAX_STREAM_DATA. The TLS ClientHello is exempt
+from flow control because it needs to be sent in a single packet regardless of
+the server's flow control state. This rule applies even for 0-RTT handshakes
+where the remembered value of MAX_STREAM_DATA would not permit sending a full
+initial cryptographic handshake message.
 
 Flow control is described in detail in {{flow-control}}, and congestion control
 is described in the companion document {{QUIC-RECOVERY}}.