Change:
URL 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.
NAME does this sound normal to you?
To clarify, I +1'd your suggestion. More clearly: "Looks good, but I would like you to accept Dimitri'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 URL
As I said in that discussion, I don'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 didn'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 Dimitri's suggestion

Discussion:
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that incoming data is being discarded on receipt at application request. <del> This signals a peer to abruptly terminate transmission on a stream. 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. </del> <ins> STOP_SENDING requests that a peer cease transmission on a stream. 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. </ins> The STOP_SENDING frame is as follows:

inform a peer of the maximum amount of data that can be sent on a stream. <del> An endpoint that receives a MAX_STREAM_DATA frame for a receive-only </del> <ins> 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 </ins> stream MUST terminate the connection with error STREAM_STATE_ERROR. <del> 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. Note that an endpoint may legally receive a MAX_STREAM_DATA frame on a bidirectional stream it has not opened. </del> The MAX_STREAM_DATA frame is as follows: MAX_STREAM_DATA frames contain the following fields: