Draft: draft-ietf-quic-transport

Commentary: I had partially settled on " send stream " and " received stream " , but on reflection these are inaccurate labels and using " parts " is better , even if it is a little more clumsy at times . 
 It you find " parts " to be clumsy would " side " be any cleaner ? 
 :) " sending side " or " sending part " is just clumsy . Nothing to be done without minting a new term , which I will not do because it 's just not that many instances to worry about . 
 The text in 3.1 and 3.2 is inconsistent about using " sending part " and " send stream " . Because bidi streams are n't a pair of uni streams , this is confusing . It would help to either clarify or use " sending part " or something . 
 ( For those following along at home , this is the transport draft . ) 0 states : I think it 's actually perfectly reasonable to consider a bidirectional stream as consisting of two unidirectional streams with some limited ways that one stream 's state change can cause the other stream 's state change . However , it 's probably worth making sure the terminology is consistent throughout .
Paragraph (version A):
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a send
stream to enter the "Send" state.  An implementation might choose to
defer allocating a stream ID to a send stream until it sends the
first frame and enters this state, which can allow for better stream
prioritization.
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 frame and enters this state, which
can allow for better stream prioritization.
Paragraph (version A):
After the application indicates that all stream data has been sent
and a STREAM frame containing the FIN bit is sent, the send stream
enters the "Data Sent" state.  From this state, the endpoint only
retransmits stream data as necessary.  The endpoint does not need to
check flow control limits or send STREAM_DATA_BLOCKED frames for a
send stream in this state.  MAX_STREAM_DATA frames might be received
until the peer receives the final stream offset.  The endpoint can
safely ignore any MAX_STREAM_DATA frames it receives from its peer
for a stream in this state.
Paragraph (version A):
Once all stream data has been successfully acknowledged, the send
stream enters the "Data Recvd" state, which is a terminal state.
Paragraph (version B):
After the application indicates that all stream data has been sent
and a STREAM frame containing the FIN bit is sent, the sending part
of the stream enters the "Data Sent" state.  From this state, the
endpoint only retransmits stream data as necessary.  The endpoint
does not need to check flow control limits or send
STREAM_DATA_BLOCKED frames for a stream in this state.
MAX_STREAM_DATA frames might be received until the peer receives the
final stream offset.  The endpoint can safely ignore any
MAX_STREAM_DATA frames it receives from its peer for a stream in this
state.
Paragraph (version B):
Once all stream data has been successfully acknowledged, the sending
part of the stream enters the "Data Recvd" state, which is a terminal
state.
Paragraph (version A):
An endpoint MAY send a RESET_STREAM as the first frame on a send
stream; this causes the send stream to open and then immediately
transition to the "Reset Sent" state.
Paragraph (version A):
Once a packet containing a RESET_STREAM has been acknowledged, the
send stream enters the "Reset Recvd" state, which is a terminal
state.
Paragraph (version A):
fig-stream-recv-states shows the states for the part of a stream that
receives data from a peer.  The states for a receive stream mirror
only some of the states of the send stream at the peer.  A receive
stream does not track states on the send stream that cannot be
observed, such as the "Ready" state.  Instead, receive streams track
the delivery of data to the application, some of which cannot be
observed by the sender.
Paragraph (version A):
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part.  The initial state for a
receive stream is "Recv".
Paragraph (version A):
The receive stream enters the "Recv" state when the sending part of a
bidirectional stream initiated by the endpoint (type 0 for a client,
type 1 for a server) enters the "Ready" state.
Paragraph (version B):
An endpoint MAY send a RESET_STREAM as the first frame that mentions
a stream; this causes the sending part of that stream to open and
then immediately transition to the "Reset Sent" state.
Paragraph (version B):
Once a packet containing a RESET_STREAM has been acknowledged, the
sending part of the stream enters the "Reset Recvd" state, which is a
terminal state.
Paragraph (version B):
fig-stream-recv-states shows the states for the part of a stream that
receives data from a peer.  The states for a receiving part of a
stream mirror only some of the states of the sending part of the
stream at the peer.  The receiving part of a stream does not track
states on the sending part that cannot be observed, such as the
"Ready" state.  Instead, the receiving part of a stream tracks the
delivery of data to the application, some of which cannot be observed
by the sender.
Paragraph (version B):
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part.  The initial state for the
receiving part of stream is "Recv".
Paragraph (version B):
The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state.
Paragraph (version A):
When a STREAM frame with a FIN bit is received, the final offset is
known (see final-offset).  The receive stream enters the "Size Known"
state.  In this state, the endpoint no longer needs to send
MAX_STREAM_DATA frames, it only receives any retransmissions of
stream data.
Paragraph (version A):
Once all data for the stream has been received, the receive stream
enters the "Data Recvd" state.  This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size
Known".  In this state, the endpoint has all stream data.  Any STREAM
or STREAM_DATA_BLOCKED frames it receives for the stream can be
discarded.
Paragraph (version B):
When a STREAM frame with a FIN bit is received, the final offset is
known (see final-offset).  The receiving part of the stream then
enters the "Size Known" state.  In this state, the endpoint no longer
needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data.
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".  In this state, the endpoint has all stream data.  Any STREAM
or STREAM_DATA_BLOCKED frames it receives for the stream can be
discarded.
Paragraph (version A):
In the latter case, the receive stream transitions from "Reset Recvd"
to "Data Recvd".
Paragraph (version A):
Once the application has been delivered the signal indicating that
the receive stream was reset, the receive stream transitions to the
"Reset Read" state, which is a terminal state.
Paragraph (version B):
In the latter case, the receiving part of the stream transitions from
"Reset Recvd" to "Data Recvd".
Paragraph (version B):
Once the application has been delivered 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):
A bidirectional stream is composed of a send stream and a receive
stream.  Implementations may represent states of the bidirectional
stream as composites of send and receive stream states.  The simplest
model presents the stream as "open" when either send or receive
stream is in a non-terminal state and "closed" when both send and
receive streams are in a terminal state.
Paragraph (version A):
stream-bidi-mapping shows a more complex mapping of bidirectional
stream states that loosely correspond to the stream states in HTTP/2
HTTP2.  This shows that multiple states on send or receive streams
are mapped to the same composite state.  Note that this is just one
possibility for such a mapping; this mapping requires that data is
acknowledged before the transition to a "closed" or "half-closed"
state.
Paragraph (version A):
A stream is considered "idle" if it has not yet been created, or
if the receive stream is in the "Recv" state without yet having
received any frames.
Paragraph (version B):
A bidirectional stream is composed of sending and receiving parts.
Implementations may represent states of the bidirectional stream as
composites of sending and receiving stream states.  The simplest
model presents the stream as "open" when either sending or receiving
parts are in a non-terminal state and "closed" when both sending and
receiving streams are in terminal states.
Paragraph (version B):
stream-bidi-mapping shows a more complex mapping of bidirectional
stream states that loosely correspond to the stream states in HTTP/2
HTTP2.  This shows that multiple states on sending or receiving parts
of streams are mapped to the same composite state.  Note that this is
just one possibility for such a mapping; this mapping requires that
data is acknowledged before the transition to a "closed" or "half-
closed" state.
Paragraph (version B):
A stream is considered "idle" if it has not yet been created, or
if the receiving part of the stream is in the "Recv" state without
yet having received any frames.
Paragraph (version A):
If the STOP_SENDING frame is received on a send stream that is
already in the "Data Sent" state, an endpoint that wishes to cease
retransmission of previously-sent STREAM frames on that stream MUST
first send a RESET_STREAM frame.
Paragraph (version A):
STOP_SENDING SHOULD only be sent for a receive stream that has not
been reset.  STOP_SENDING is most useful for streams in the "Recv" or
"Size Known" states.
Paragraph (version B):
If the STOP_SENDING frame is received on a stream that is already in
the "Data Sent" state, an endpoint that wishes to cease
retransmission of previously-sent STREAM frames on that stream MUST
first send a RESET_STREAM frame.
Paragraph (version B):
STOP_SENDING SHOULD only be sent for a stream that has not been reset
by the peer.  STOP_SENDING is most useful for streams in the "Recv"
or "Size Known" states.
Paragraph (version A):
An endpoint will know the final offset for a stream when the receive
stream enters the "Size Known" or "Reset Recvd" state (stream-
states).
Paragraph (version B):
An endpoint will know the final offset for a stream when the
receiving part of the stream enters the "Size Known" or "Reset Recvd"
state (stream-states).
Paragraph (version A):
Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the send stream).  The content of
a RESET_STREAM frame MUST NOT change when it is sent again.
Paragraph (version A):
Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receive stream enters
either a "Data Recvd" or "Reset Recvd" state, see solicited-state-
transitions.
Paragraph (version B):
Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is
sent again.
Paragraph (version B):
Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state, see
solicited-state-transitions.
Paragraph (version A):
The current maximum stream data offset is sent in MAX_STREAM_DATA
frames.  Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the
frame from being sent too often.  An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receive stream enters a "Size
Known" state.
Paragraph (version B):
The current maximum stream data offset is sent in MAX_STREAM_DATA
frames.  Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the
frame from being sent too often.  An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receiving part of the stream
enters a "Size Known" state.
Paragraph (version A):
Receipt of a STOP_SENDING frame is invalid for a locally-initiated
stream that has not yet been created or is in the "Ready" state (see
stream-send-states).  Receiving a STOP_SENDING frame for a locally-
initiated send stream that is "Ready" or not yet created MUST be
treated as a connection error of type PROTOCOL_VIOLATION.  An
endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error PROTOCOL_VIOLATION.
Paragraph (version B):
Receipt of a STOP_SENDING frame is invalid for a locally-initiated
stream that has not yet been created or is in the "Ready" state (see
stream-send-states).  Receiving a STOP_SENDING frame for a locally-
initiated stream that is "Ready" or not yet created MUST be treated
as a connection error of type PROTOCOL_VIOLATION.  An endpoint that
receives a STOP_SENDING frame for a receive-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.