Independent states and STOP_SENDING

draft-ietf-quic-http.md

@@ -276,11 +276,11 @@ A server can send a complete response prior to the client sending an entire
 request if the response does not depend on any portion of the request that has
 not been sent and received. When this is true, a server MAY request that the
 client abort transmission of a request without error by triggering a QUIC
-DISINTEREST with error code HTTP_EARLY_RESPONSE, sending a complete response,
+STOP_SENDING with error code HTTP_EARLY_RESPONSE, sending a complete response,
 and cleanly closing its streams. Clients MUST NOT discard complete responses as
-a result of receiving a DISINTEREST, though clients can always discard responses
-at their discretion for other reasons.  Servers SHOULD NOT abort a response in
-progress as a result of receiving a solicited RST_STREAM.
+a result of receiving a STOP_SENDING, though clients can always discard
+responses at their discretion for other reasons.  Servers SHOULD NOT abort a
+response in progress as a result of receiving a solicited RST_STREAM.
 
 ### Header Compression
 
@@ -379,7 +379,7 @@ frames sent on the control stream, and response body (if any) sent via the
 corresponding data stream.
 
 If a promised push stream is not needed by the client, the client SHOULD send a
-QUIC DISINTEREST on the promised stream with an appropriate error code (e.g.
+QUIC STOP_SENDING on the promised stream with an appropriate error code (e.g.
 HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}).  This asks the
 server not to transfer the data and indicates that it will be discarded upon
 receipt.

draft-ietf-quic-transport.md

@@ -2470,16 +2470,15 @@ but loss or reordering can cause packets that open streams to arrive out of
 order.
 
 From the "open" state, either endpoint can send a frame with the FIN flag set,
-which causes the stream to transition into one of the "half-closed" states.
-This flag can be set on the frame that opens the stream, which causes the stream
-to immediately become "half-closed".  Once an endpoint has completed sending all
+which causes the stream to transition into one of the "half-closed" states. This
+flag can be set on the frame that opens the stream, which causes the stream to
+immediately become "half-closed".  Once an endpoint has completed sending all
 stream data and a STREAM frame with a FIN flag, the stream state becomes
-"half-closed (local)".  When an endpoint receives all stream data a FIN flag the
-stream state becomes "half-closed (remote)".  An endpoint MUST NOT consider the
-stream state to have changed until all data has been sent, received or
-discarded.
+"half-closed (local)".  When an endpoint receives all stream data and a FIN flag
+the stream state becomes "half-closed (remote)".  An endpoint MUST NOT consider
+the stream state to have changed until all data has been sent or received.
 
-A RST_STREAM frame on an "open" stream causes the stream to become
+A RST_STREAM frame on an "open" stream also causes the stream to become
 "half-closed".  A stream that becomes "open" as a result of sending or receiving
 RST_STREAM immediately becomes "half-closed".  Sending a RST_STREAM frame causes
 the stream to become "half-closed (local)"; receiving RST_STREAM causes the
@@ -2518,10 +2517,6 @@ received data.
 Once all data has been either received or discarded, a sender is no longer
 obligated to update the maximum received data for the connection.
 
-An endpoint that receives a RST_STREAM frame (and which has not sent a FIN or a
-RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUST NOT send
-any more data on the stream.
-
 Due to reordering, an endpoint could continue receiving frames for the stream
 even after the stream is closed for sending.  Frames received after a peer
 closes a stream SHOULD be discarded.  An endpoint MAY choose to limit the period
@@ -2536,11 +2531,10 @@ mentions a stream ID.  In this state, the endpoint MUST observe advertised
 stream and connection data limits (see {{flow-control}}).
 
 A stream transitions from this state to "closed" by completing transmission of
-all data.  This includes sending all data carried in STREAM frames up including
-the terminal STREAM frame that contains a FIN flag.
+all data.  This includes sending all data carried in STREAM frames up to and
+including the terminal STREAM frame that contains a FIN flag.
 
-A stream becomes "closed" when the endpoint sends and receives acknowledgment of
-a RST_STREAM frame.
+A stream also becomes "closed" when the endpoint sends a RST_STREAM frame.
 
 
 ### closed {#state-closed}
@@ -2741,12 +2735,12 @@ controller.
 
 ### Response to a RST_STREAM
 
-RST_STREAM terminates a stream abruptly.  Whether any action or response can or
-should be taken on the data already received is an application-specific issue,
-but it will often be the case that upon receipt of a RST_STREAM an endpoint
-will choose to stop sending data in its own direction. If the sender of a
-RST_STREAM wishes to explicitly state that no future data will be processed,
-that endpoint MAY send a STOP_SENDING frame at the same time.
+RST_STREAM terminates one direction of a stream abruptly.  Whether any action or
+response can or should be taken on the data already received is an
+application-specific issue, but it will often be the case that upon receipt of a
+RST_STREAM an endpoint will choose to stop sending data in its own direction. If
+the sender of a RST_STREAM wishes to explicitly state that no future data will
+be processed, that endpoint MAY send a STOP_SENDING frame at the same time.
 
 ### Data Limit Increments {#fc-credit}