Independent states and STOP_SENDING

draft-ietf-quic-transport.md

@@ -1791,50 +1791,40 @@ stream, but is unable to due to the maximum stream ID limit.
 The STREAM_ID_NEEDED frame does not contain a payload.
 
 
+## NEW_CONNECTION_ID Frame {#frame-new-connection-id}
 
-## RST_STREAM Frame {#frame-rst-stream}
-
-An endpoint may use a RST_STREAM frame (type=0x01) to abruptly terminate a
-stream.
-
-After sending a RST_STREAM, an endpoint ceases transmission of STREAM frames on
-the identified stream.  A receiver of RST_STREAM can discard any data that it
-already received on that stream.  An endpoint sends a RST_STREAM in response to
-a RST_STREAM unless the stream is already closed.
+A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the client with
+alternative connection IDs that can be used to break linkability when migrating
+connections (see {{migration-linkability}}).
 
-The RST_STREAM frame is as follows:
+The NEW_CONNECTION_ID is as follows:
 
 ~~~
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                        Stream ID (32)                         |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                        Error Code (32)                        |
+|       Sequence (16)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
-+                       Final Offset (64)                       +
++                        Connection ID (64)                     +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
 The fields are:
 
-Stream ID:
-
-: The 32-bit Stream ID of the stream being terminated.
-
-Error code:
-
-: A 32-bit error code which indicates why the stream is being closed.
-
-Final offset:
-
-: A 64-bit unsigned integer indicating the absolute byte offset of the end of
-  data written on this stream by the RST_STREAM sender.
+Sequence:
 
+: A 16-bit sequence number.  This value starts at 0 and increases by 1 for each
+  connection ID that is provided by the server.  The sequence value can wrap;
+  the value 65535 is followed by 0.  When wrapping the sequence field, the
+  server MUST ensure that a value with the same sequence has been received and
+  acknowledged by the client.  The connection ID that is assigned during the
+  handshake is assumed to have a sequence of 65535.
 
+Connection ID:
 
+: A 64-bit connection ID.
 
 ## DISINTEREST Frame {#frame-disinterest}
 
@@ -1855,63 +1845,6 @@ The fields are:
 * Stream ID: The 32-bit Stream ID of the stream being ignored.
 
 
-## PADDING Frame {#frame-padding}
-
-The PADDING frame (type=0x00) has no semantic value.  PADDING frames can be used
-to increase the size of a packet.  Padding can be used to increase an initial
-client packet to the minimum required size, or to provide protection against
-traffic analysis for protected packets.
-
-A PADDING frame has no content.  That is, a PADDING frame consists of the single
-octet that identifies the frame as a PADDING frame.
-
-
-## PING frame {#frame-ping}
-
-Endpoints can use PING frames (type=0x07) to verify that their peers are still
-alive or to check reachability to the peer. The PING frame contains no
-additional fields. The receiver of a PING frame simply needs to acknowledge the
-packet containing this frame. The PING frame SHOULD be used to keep a connection
-alive when a stream is open. The default is to send a PING frame after 15
-seconds of quiescence. A PING frame has no additional fields.
-
-
-## NEW_CONNECTION_ID Frame {#frame-new-connection-id}
-
-A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the client with
-alternative connection IDs that can be used to break linkability when migrating
-connections (see {{migration-linkability}}).
-
-The NEW_CONNECTION_ID is as follows:
-
-~~~
- 0                   1                   2                   3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|       Sequence (16)           |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                                                               |
-+                        Connection ID (64)                     +
-|                                                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~~~
-
-The fields are:
-
-Sequence:
-
-: A 16-bit sequence number.  This value starts at 0 and increases by 1 for each
-  connection ID that is provided by the server.  The sequence value can wrap;
-  the value 65535 is followed by 0.  When wrapping the sequence field, the
-  server MUST ensure that a value with the same sequence has been received and
-  acknowledged by the client.  The connection ID that is assigned during the
-  handshake is assumed to have a sequence of 65535.
-
-Connection ID:
-
-: A 64-bit connection ID.
-
-
 ## ACK Frame {#frame-ack}
 
 Receivers send ACK frames to inform senders which packets they have received and