Draft: draft-ietf-quic-transport

Commentary: the case where those streams are implicitly created . There 's probably another state here if we were being entirely honest with ourselves to distinguish between a stream that has been created and one that has had frames sent for it , but this is already more complex than it needs to be . 
 does this sound normal to you ? 
 To clarify , I +1'd your suggestion . More clearly : " Looks good , but I would like you to accept  's suggestion before submitting this PR . " 
 Ah , alright . I thought it was the other way around . 
 This LGTM . I was just about to file a similar issue when I saw this . 
 MAXSTREAMDATA should not be able to be transmitted on uni - directional until frames have been received on the same or a higher numbered stream of same type . Or until the stream is created for bidi streams . If this is not the case , a peer can force the initiator to track unbounded state and frames or risk frames being received when an endpoint is not ready to handle them . See discussion here 
 As I said in that discussion , I do n't think there 's an unresolved issue here . : 
 Sorry if that is the case . My impression was that you used it as an example to where we did not have such protection , and did n't care . I 'll leave it open for now since the term " has not opened " is also a bit vague . Exactly what state must the sender be in for this to count ? And what must the peer observe to conclude this ? 
 This is a non - issue , with the clarifications in the PRs incoming . That is , you can only receive MAXSTREAMDATA for a stream that you have decided to open . At that point you have decided to track considerably more state than a flow control limit . We can leave this until or similar lands . 
 Thanks 
 LG minus  's suggestion
Paragraph (version A):
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request.
This signals a peer to abruptly terminate transmission on a stream.
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 stream that is "Ready" or not yet created MUST be treated
as a connection error of type STREAM_STATE_ERROR.  An endpoint that
receives a STOP_SENDING frame for a receive-only stream MUST
terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream.
Paragraph (version B):
A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states (see stream-send-states).  Receiving a STOP_SENDING
frame for a locally-initiated stream that has not yet been created
MUST be treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
An endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
An endpoint that receives a MAX_STREAM_DATA frame for a send-only
stream it has not opened MUST terminate the connection with error
STREAM_STATE_ERROR.
Paragraph (version A):
Note that an endpoint may legally receive a MAX_STREAM_DATA frame on
a bidirectional stream it has not opened.
Paragraph (version B):
A MAX_STREAM_DATA frame can be sent for streams in the Recv state
(see stream-send-states).  Receiving a MAX_STREAM_DATA frame for a
locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.