Draft: draft-ietf-quic-transport

Commentary: Feel free to take the suggestions you like and revert or fix the others . 
 In most places in QUIC , if an error is clearly avoidable(ie : only a buggy implementation would do so ) , then we advise closing the connection with an error , not just closing the stream with an error . In section 4.5 of transport ( ) it says : " Endpoints MUST NOT exceed the limit set by their peer . An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAMLIMITERROR " Came up in discussion of 
 As I commented in the updated PR description , section 19.11 already says this : " An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted . " 
 Reopening to keep this visible . 
 is effectively the proposal , correct ? 
 Yes . It was editorial . So I merged it . But then this issue really is n't editorial . 
 Yes , I opened this issue , then found that text in section 19.11 in the doc said exceeding  was a connection error , so the PR ended up aligning the two sections .
Paragraph (version A):
The smallest unit of QUIC that can be encapsulated in a UDP
datagram.  Multiple QUIC packets can be encapsulated in a single
UDP datagram.
Paragraph (version A):
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application.  An alternative view of QUIC streams
is as an elastic "message" abstraction.
Paragraph (version A):
Streams are an ordered byte-stream abstraction with no other
structure that is visible to QUIC.  STREAM frame boundaries are not
expected to be preserved when data is transmitted, when data is
retransmitted after packet loss, or when data is delivered to the
application at a receiver.
Paragraph (version B):
Streams are an ordered byte-stream abstraction with no other
structure visible to QUIC.  STREAM frame boundaries are not expected
to be preserved when data is transmitted, retransmitted after packet
loss, or delivered to the application at a receiver.
Paragraph (version A):
QUIC does not provide frames for exchanging prioritization
information.  Instead it relies on receiving priority information
from the application that uses QUIC.
Paragraph (version B):
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
sending part of a stream to enter the "Send" state.  An
implementation might choose to defer allocating a stream ID to a
stream until it sends the first STREAM frame and enters this state,
which can allow for better stream prioritization.
Paragraph (version B):
Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state.  This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size
Known".  After all data has been received, any STREAM or
STREAM_DATA_BLOCKED frames for the stream can be discarded.
Paragraph (version B):
Once the application receives the signal indicating that the stream
was reset, the receiving part of the stream transitions to the "Reset
Read" state, which is a terminal state.
Paragraph (version A):
STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames
will be discarded upon receipt.
Paragraph (version A):
A receiver can advertise a larger offset by sending MAX_STREAM_DATA
or MAX_DATA frames at any time during the connection.  A receiver
cannot renege on an advertisement however.  That is, once a receiver
advertises an offset, it MAY advertise a smaller offset, but this has
no effect.
Paragraph (version A):
If a sender runs out of flow control credit, it will be unable to
send new data and is considered blocked.  A sender SHOULD send
STREAM_DATA_BLOCKED or DATA_BLOCKED frames to indicate it has data to
write but is blocked by flow control limits.  These frames are
expected to be sent infrequently in common cases, but they are
considered useful for debugging and monitoring purposes.
Paragraph (version A):
A sender sends a single STREAM_DATA_BLOCKED or DATA_BLOCKED frame
only once when it reaches a data limit.  A sender SHOULD NOT send
multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames for the same data
limit, unless the original frame is determined to be lost.  Another
STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
limit is increased.
Paragraph (version A):
On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that
stream.  If a RESET_STREAM frame is reordered with stream data for
the same stream, the receiver's estimate of the number of bytes
received on that stream can be lower than the sender's estimate of
the number sent.  As a result, the two endpoints could disagree on
the number of bytes that count towards connection flow control.
Paragraph (version A):
A receiver cannot renege on an advertisement.  That is, once a
receiver advertises a stream limit using the MAX_STREAMS frame,
advertising a smaller limit has no effect.  A receiver MUST ignore
any MAX_STREAMS frame that does not increase the stream limit.