rename to CLOSE_STREAM, make error code optional

draft-ietf-quic-reliable-stream-reset.md

@@ -37,9 +37,9 @@ QUIC ({{!RFC9000}}) defines a RESET_STREAM frame to reset a stream. When a
 sender resets a stream, it stops retransmitting STREAM frames for this stream.
 On the receiver side, there is no guarantee that any of the data sent on that
 stream is delivered to the application.
-This document defines a new QUIC frame, the RELIABLE_RESET_STREAM frame, that
-resets a stream, while guaranteeing reliable delivery of stream data up to a
-certain byte offset.
+This document defines a new QUIC frame, the CLOSE_STREAM frame, that allows
+closing and resetting of a stream, while guaranteeing reliable delivery of
+stream data up to a certain byte offset.
 
 --- middle
 
@@ -66,7 +66,7 @@ might want to use a stream reset to signal that error, at the same time making
 sure that all data being read previously is delivered to the peer.
 
 This document describes a QUIC extension defining a new frame type, the
-RELIABLE_RESET_STREAM frame. This frame allows an endpoint to mark a portion at
+CLOSE_STREAM frame. This frame allows an endpoint to mark a portion at
 the beginning of the stream which will then be guaranteed to be delivered to
 receiver's application, even if the stream was reset.
 
@@ -77,7 +77,7 @@ receiver's application, even if the stream was reset.
 # Negotiating Extension Use
 
 Endpoints advertise their support of the extension described in this document by
-sending the reliable_reset_stream (0x727273) transport parameter
+sending the close_stream (0x17f7586d2cb570) transport parameter
 (Section 7.4 of {{!RFC9000}}) with an empty value. An implementation that
 understands this transport parameter MUST treat the receipt of a non-empty
 value as a connection error of type TRANSPORT_PARAMETER_ERROR.
@@ -87,29 +87,30 @@ remember the value of this transport parameter.  If 0-RTT data is accepted by
 the server, the server MUST not disable this extension on the resumed
 connection.
 
-# RELIABLE_RESET_STREAM Frame
+# CLOSE_STREAM Frame
 
-Conceptually, the RELIABLE_RESET_STREAM frame is a RESET_STREAM frame with an
+Conceptually, the CLOSE_STREAM frame is a RESET_STREAM frame with an
 added Reliable Size field.
 
 ~~~
-RELIABLE_RESET_STREAM Frame {
-  Type (i) = 0x72,
+CLOSE_STREAM Frame {
+  Type (i) = 0x20..0x21,
   Stream ID (i),
-  Application Protocol Error Code (i),
+  [Application Protocol Error Code (i)],
   Final Size (i),
   Reliable Size (i),
 }
 ~~~
 
-RELIABLE_RESET_STREAM frames contain the following fields:
+The CLOSE_STREAM frames contain the following fields:
 
 Stream ID:  A variable-length integer encoding of the stream ID of
       the stream being terminated.
 
 Application Protocol Error Code:  A variable-length integer
     containing the application protocol error code (see Section 20.2)
-    that indicates why the stream is being closed.
+    that indicates why the stream is being closed. If the Type is 0x20,
+    this field is not included.
 
 Final Size:  A variable-length integer indicating the final size of
     the stream by the RESET_STREAM sender, in units of bytes; see
@@ -122,50 +123,62 @@ Reliable Size:  A variable-length integer indicating the amount of
 If the Reliable Size is larger than the Final Size, the receiver MUST close the
 connection with a connection error of type FRAME_ENCODING_ERROR.
 
-Semantically, a RESET_STREAM frame is equivalent to a RELIABLE_RESET_STREAM
-frame with the Reliable Size set to 0.
+CLOSE_STREAM frames are ack-eliciting. When lost, they MUST be retransmitted,
+unless another frame that causes a state transition to the Data Sent or Reset
+Sent State was sent for the same stream (see {{multiple-frames}}).
 
-RELIABLE_RESET_STREAM frames are ack-eliciting. When lost, they MUST be
-retransmitted, unless a RESET_STREAM frame or another RELIABLE_RESET_STREAM
-frame was sent for the same stream (see {{multiple-frames}}).
+# Closing Streams
 
-# Resetting Streams
+## Without an Error
+
+When closing a stream with an error, the node has the choise between a STREAM
+frame that carries the FIN bit and a CLOSE_STREAM frame of type 0x20.
+
+The CLOSE_STREAM frame can be used to reduce the reliable offset after a
+STREAM frame with a FIN bit has been sent. If STREAM frames containing data
+up to that byte offset are lost, the initiator MUST retransmit this data, as
+described in (Section 13.3 of {{!RFC9000}}). Data sent beyond that byte offset
+SHOULD NOT be retransmitted.
+
+## Using an Error Code
 
 When resetting a stream, the node has the choice between using a RESET_STREAM
-frame and a RELIABLE_RESET_STREAM frame. When using a RESET_STREAM frame, the
-behavior is unchanged from the behavior described in ({{!RFC9000}}).
+frame and a CLOSE_STREAM frame of type 0x21. When using a RESET_STREAM frame,
+the behavior is unchanged from the behavior described in ({{!RFC9000}}).
 
 The initiator MUST guarantee reliable delivery of stream data of at least
 Reliable Size bytes.  If STREAM frames containing data up to that byte offset
-are lost, the initiator MUST retransmit this data,  as described in
+are lost, the initiator MUST retransmit this data, as described in
 (Section 13.3 of {{!RFC9000}}). Data sent beyond that byte offset SHOULD NOT be
 retransmitted.
 
 As described in (Section 3.2 of {{RFC9000}}), it MAY deliver data beyond that
 offset to the application.
 
-## Multiple RELIABLE_RESET_STREAM / RESET_STREAM frames {#multiple-frames}
+## Multiple CLOSE_STREAM / RESET_STREAM frames {#multiple-frames}
 
-The initiator MAY send multiple RELIABLE_RESET_STREAM frames for the same
+The initiator MAY send multiple CLOSE_STREAM frames for the same
 stream in order to reduce the Reliable Size.  It MAY also send a RESET_STREAM
-frame, which is equivalent to sending a RELIABLE_RESET_STREAM frame with a
+frame, which is equivalent to sending a CLOSE_STREAM frame with a
 Reliable Size of 0.
 
 When sending multiple frames for the same stream, the initiator MUST NOT increase
-the Reliable Size.  When receiving a RELIABLE_RESET_STREAM frame with a lower
+the Reliable Size.  When receiving a CLOSE_STREAM frame with a lower
 Reliable Size, the receiver only needs to deliver data up the lower Reliable
 Size to the application. It MUST NOT expect the delivery of any data beyond that
 byte offset.
 
-Reordering of packets might lead to a RELIABLE_RESET_STREAM frame with a higher
-Reliable Size being received after a RELIABLE_RESET_STREAM frame with a lower
-Reliable Size.  The receiver MUST ignore any RELIABLE_RESET_STREAM frame that
+Reordering of packets might lead to a CLOSE_STREAM frame with a higher
+Reliable Size being received after a CLOSE_STREAM frame with a lower
+Reliable Size.  The receiver MUST ignore any CLOSE_STREAM frame that
 increases the Reliable Size.
 
-When sending another RELIABLE_RESET_STREAM or RESET_STREAM frame for the same
-stream, the initiator MUST NOT change the Application Error Code or the Final
-Size. If the receiver detects a change in those fields, it MUST close the
-connection with a connection error of type STREAM_STATE_ERROR.
+When sending another CLOSE_STREAM, RESET_STREAM or STREAM frame carrying a FIN
+bit for the same stream, the initiator MUST NOT change the Application Error
+Code or the Final Size.  This also means that sending CLOSE_STREAM frames of
+different types is not permitted. If the receiver detects a change in those
+fields, it MUST close the connection with a connection error of type
+STREAM_STATE_ERROR.
 
 # Security Considerations