Complete the changes

draft-ietf-quic-http.md

@@ -304,13 +304,14 @@ TCP server; data received from the TCP server is packaged into DATA frames by
 the proxy. Note that the size and number of TCP segments is not guaranteed to
 map predictably to the size and number of HTTP DATA or QUIC STREAM frames.
 
-The TCP connection can be closed by either peer. When the client half-closes the
-request stream, the proxy will set the FIN bit on its connection to the TCP
-server. When the proxy receives a packet with the FIN bit set, it will
-half-close the corresponding stream. TCP connections which remain half-closed in
-a single direction are not invalid, but are often handled poorly by servers, so
-clients SHOULD NOT half-close connections on which they are still expecting
-data.
+The TCP connection can be closed by either peer. When the client ends the
+request stream (that is, the receive stream at the proxy enters the "Data Recvd"
+state), the proxy will set the FIN bit on its connection to the TCP server. When
+the proxy receives a packet with the FIN bit set, it will terminate the send
+stream that it sends to client. TCP connections which remain half-closed in a
+single direction are not invalid, but are often handled poorly by servers, so
+clients SHOULD NOT cause send a STREAM frame with a FIN bit for connections on
+which they are still expecting data.
 
 A TCP connection error is signaled with RST_STREAM. A proxy treats any error in
 the TCP connection, which includes receiving a TCP segment with the RST bit set,

draft-ietf-quic-transport.md

@@ -1952,11 +1952,11 @@ Maximum Data:
 
 All data sent in STREAM frames counts toward this limit, with the exception of
 data on stream 0.  The sum of the largest received offsets on all streams -
-including closed streams, but excluding stream 0 - MUST NOT exceed the value
-advertised by a receiver.  An endpoint MUST terminate a connection with a
-QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more data than the
-maximum data value that it has sent, unless this is a result of a change in the
-initial limits (see {{zerortt-parameters}}).
+including streams in terminal states, but excluding stream 0 - MUST NOT exceed
+the value advertised by a receiver.  An endpoint MUST terminate a connection
+with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more data
+than the maximum data value that it has sent, unless this is a result of a
+change in the initial limits (see {{zerortt-parameters}}).
 
 
 ## MAX_STREAM_DATA Frame {#frame-max-stream-data}
@@ -2577,14 +2577,16 @@ When a packet is detected as lost, the sender re-sends any frames as necessary:
 * ACK and PADDING frames MUST NOT be retransmitted.  ACK frames
   containing updated information will be sent as described in {{frame-ack}}.
 
-* STOP_SENDING frames MUST be retransmitted, unless the stream has become closed
-  in the appropriate direction.  See {{solicited-state-transitions}}.
+* STOP_SENDING frames MUST be retransmitted until the receive stream enters
+  either a "Data Recvd" or "Reset Recvd" state.  See
+  {{solicited-state-transitions}}.
 
-* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any
-  previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT
-  be retransmitted since a newer MAX_STREAM_DATA frame for a stream obviates the
-  need for delivering older ones. Similarly, the most recent MAX_DATA frame MUST
-  be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted.
+* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted until
+  the receive stream enters a "Size Known" state. Any previous unacknowledged
+  MAX_STREAM_DATA frame for the same stream SHOULD NOT be retransmitted since a
+  newer MAX_STREAM_DATA frame for a stream obviates the need for delivering
+  older ones. Similarly, the most recent MAX_DATA frame MUST be retransmitted;
+  previous unacknowledged ones SHOULD NOT be retransmitted.
 
 * All other frames MUST be retransmitted.
 
@@ -2700,10 +2702,10 @@ in both directions.
 Opening a stream causes all lower-numbered streams of the same type to
 implicitly open.  This includes both send and receive streams if the stream is
 bidirectional.  For bidirectional streams, an endpoint can send data on an
-implicitly opened a stream.  On both unidirectional and bidirectional streams,
-an endpoint MAY send MAX_STREAM_DATA or STOP_SENDING on implicitly opened
-streams.  An endpoint SHOULD NOT implicitly open streams that it initiates,
-instead opening streams in order.
+implicitly opened stream.  On both unidirectional and bidirectional streams, an
+endpoint MAY send MAX_STREAM_DATA or STOP_SENDING on implicitly opened streams.
+An endpoint SHOULD NOT implicitly open streams that it initiates, instead
+opening streams in order.
 
 Note:
 
@@ -2929,8 +2931,8 @@ the states of the pair of streams.  The simplest model presents the stream as
 states that loosely correspond to the stream states in HTTP/2
 {{?HTTP2=RFC7540}}.  This shows that multiple states on send or receive streams
 are mapped to the same composite state.  Note that this is just one possibility
-for a mapping, one that requires that data is acknowledged before the transition
-to a closed or half-closed state.
+for such a mapping; thi mapping requires that data is acknowledged before the
+transition to a "closed" or "half-closed" state.
 
 | Send Stream            | Receive Stream         | Composite State      |
 |:-----------------------|:-----------------------|:---------------------|
@@ -2950,7 +2952,7 @@ to a closed or half-closed state.
 Note (*1):
 
 : A stream is considered "idle" if it has not yet been created, or if the
-  receive stream is in the Recv state without yet having received any frames.
+  receive stream is in the "Recv" state without yet having received any frames.
 
 
 ## Solicited State Transitions
@@ -2966,19 +2968,21 @@ connection and stream flow-control windows, even though these frames will be
 discarded upon receipt.  This avoids potential ambiguity about which STREAM
 frames count toward flow control.
 
-STOP_SENDING can only be sent for any stream that is not "idle", however it is
-mostly useful for streams in the "open" or "half-closed (local)" states.  A
-STOP_SENDING frame requests that the receiving endpoint send a RST_STREAM frame.
-An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM frame for
-that stream with an error code of STOPPING.  If the STOP_SENDING frame is
-received on a stream that is already in the "half-closed (local)" or "closed"
-states, a RST_STREAM frame MAY still be sent in order to cancel retransmission
-of previously-sent STREAM frames.
+A STOP_SENDING frame requests that the receiving endpoint send a RST_STREAM
+frame.  An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM
+frame for that stream, and can use an error code of STOPPING.  If the
+STOP_SENDING frame is received on a send stream that is already in the "Data
+Sent" state, a RST_STREAM frame MAY still be sent in order to cancel
+retransmission of previously-sent STREAM frames.
 
-While STOP_SENDING frames are retransmittable, an implementation MAY choose not
-to retransmit a lost STOP_SENDING frame if the stream has already been closed
-in the appropriate direction since the frame was first generated.
-See {{packetization}}.
+STOP_SENDING can only be sent for a receive stream that has not been
+reset. STOP_SENDING is most useful for streams in the "Recv" or "Size Known"
+states.
+
+An endpoint is expected to send STOP_SENDING frames if packets containing the
+frame are lost.  However, once either all stream data has been received or a
+RST_STREAM frame - that is, any receive stream state other than "Recv" or "Size
+Known" - sending the frame is not necessary.
 
 
 ## Stream Concurrency {#stream-concurrency}
@@ -3224,10 +3228,8 @@ stream.  For a stream that is reset, the final offset is carried explicitly in
 the RST_STREAM frame.  Otherwise, the final offset is the offset of the end of
 the data carried in STREAM frame marked with a FIN flag.
 
-An endpoint will know the final offset for a stream when the stream enters the
-"half-closed (remote)" state.  However, if there is reordering or loss, an
-endpoint might learn the final offset prior to entering this state if it is
-carried on a STREAM frame.
+An endpoint will know the final offset for a stream when the receive stream
+enters the "Size Known" or "Reset Recvd" state.
 
 An endpoint MUST NOT send data on a stream at or beyond the final offset.