Fixup dead reference to stream type 0xff

draft-ietf-quic-http.md

@@ -191,20 +191,20 @@ the stream management. An HTTP request/response consumes a pair of streams in
 each direction.
 
 Aside from the connection control stream, the beginning of each stream starts
-with a short stream header.  This stream header is used to identify the type of
-stream and to link the stream to another stream as necessary.  See
-{{stream-header}} for more details on the stream header.
+with a short stream header ({{stream-header}}).  This stream header is used to
+identify the type of stream and to link the stream to another stream as
+necessary.
 
 \[Editor's Note: the following is clearly busted.  Requests and responses can't
 reliably be cancelled as a result of this change.  We will need QPACK/QCRAM for
 this to work.] Request, response and push streams contain HPACK data which
 manipulates connection-level state.  Therefore, these streams MUST NOT be closed
 with a stream-level error.
 
-Streams must be opened sequentially, with no gaps.  Data streams SHOULD be
-opened after the request, response or push stream is opened.  Data streams are
-closed after transferring the body.  Data streams are not opened for messages
-that contain no body and messages that contain an empty body.
+New streams use the next available QUIC stream.  Data streams SHOULD be opened
+after the request, response or push stream is opened.  Data streams are closed
+after transferring the body.  Data streams are not opened for messages that
+contain no body and messages that contain an empty body.
 
 HTTP does not need to do any separate multiplexing when using QUIC - data sent
 over a QUIC stream always maps to a particular HTTP transaction. Requests and
@@ -248,9 +248,6 @@ There is no stream header for a connection control stream; the stream is
 identified by its stream number.  The connection control stream contains a
 sequence of frames, starting with the SETTINGS frame.
 
-If an endpoint receives a stream type of 0xff on any stream other than stream 1,
-it MUST terminate the connection with an HTTP_INVALID_STREAM_HEADER error.
-
 
 ### Request Streams {#stream-request}
 
@@ -302,7 +299,7 @@ the connection MUST be terminated with an HTTP_UNMATCHED_RESPONSE error.
 Data streams are opened by both client and server.  Data streams carry the
 payload body of requests or responses.
 
-The stream header for a response stream contains the type octet, which is set to
+The stream header for a data stream contains the type octet, which is set to
 0x02, and the stream ID of a request or response stream as a 32-bit value.
 
 ~~~~~

draft-ietf-quic-transport.md

@@ -2294,7 +2294,7 @@ actually lost.
 
 # Streams: QUIC's Data Structuring Abstraction {#streams}
 
-Streams in QUIC provide a lightweight, ordered, and unidirectional byte-stream.
+Streams in QUIC provide a lightweight, ordered, unidirectional byte-stream.
 
 Streams can be created either by the client or the server, can concurrently send
 data interleaved with other streams, and can be cancelled.
@@ -2323,10 +2323,9 @@ for some applications.
 Streams are identified by an unsigned 32-bit integer, referred to as the Stream
 ID.  A separate identifier space is used for streams sent by each peer.
 
-Stream ID 0 (0x0) in both directions is reserved for the cryptographic
-handshake.  Both client and server send cryptographic handshake messages on
-their stream 0, which is bound into a bidirectional channel.  Stream 0 MUST NOT
-be used for application data.
+Stream ID 0 in both directions is reserved for the cryptographic handshake.
+Both client and server send cryptographic handshake messages on their stream 0.
+Stream 0 MUST NOT be used for application data.
 
 A QUIC endpoint cannot reuse a Stream ID.  Streams MUST be created in sequential
 order.  Open streams can be used in any order.  Streams that are used out of
@@ -2341,10 +2340,10 @@ stream ID are zero.
 ## Stream States
 
 Endpoints do not coordinate the creation of streams; they are created
-unilaterally by either endpoint.
+unilaterally by the sending endpoint.
 
-A stream sender controls the state of its streams; the state of a stream is only
-affected by frames that are sent by the sending endpoint.  However,
+Transitions between stream states ("idle", "open", and "closed") is only
+triggered by frames that are sent by the sending endpoint.  However,
 state-affecting frames can arrive out of order at the receiving endpoint,
 leading to a different set of valid transitions for receiving streams.
 
@@ -2433,7 +2432,9 @@ Sending a STREAM or RST_STREAM frame causes the identified stream to become
 "open" for a sending endpoint.  New streams use the next available stream
 identifier, as described in {{stream-id}}.  An endpoint MUST NOT send a STREAM
 or RST_STREAM frame for a stream ID that is higher than the peers advertised
-maximum stream ID (see {{frame-max-stream-id}}).
+maximum stream ID (see {{frame-max-stream-id}}).  An endpoint MUST treat
+receiving a STREAM or RST_STREAM frame for stream above the maximum as a
+QUIC_TOO_MANY_OPEN_STREAMS error.
 
 Receiving a STREAM, RST_STREAM, or STREAM_BLOCKED frame causes a stream to
 become "open" for a receiving endpoint.
@@ -2466,8 +2467,8 @@ From the "open" state, the sending endpoint causes the stream to become "closed"
 by sending a RST_STREAM frame, or by sending a STREAM frame with the FIN flag
 set after sending all preceding data.
 
-A stream becomes "closed" at the receiving endpoint when all data is received
-and a STREAM frame with a FIN flag is received or when a RST_STREAM frame is
+A stream becomes "closed" at the receiving endpoint when a RST_STREAM frame is
+received or when all data is received and a STREAM frame with a FIN flag is
 received.