On Thu, Aug 10, 2023 at 4:56 AM Nick Banks <nibanks= [email protected]> wrote:
> Yeah, I don't think that's quite good enough. It's pretty good support > for using STREAM_STATE_ERROR, but it's not really support for the position > that an endpoint MUST terminate the connection in either case. > Of the stream-related frames, RFC 9000 19.* states: ~~~ "An endpoint that receives a RESET_STREAM frame for a send-only stream MUST terminate the connection with error STREAM_STATE_ERROR." "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." "An endpoint MUST terminate the connection with error STREAM_STATE_ERROR if it receives a STREAM frame for a locally initiated stream that has not yet been created, or for a send-only stream." "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." "An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only stream MUST terminate the connection with error STREAM_STATE_ERROR." ~~~ I don't know that it's worthy of an erratum, but the requirements are inconsistent and, and even when the requirements are consistent the language isn't. I think that ideally all of these would follow the language for STREAM frames and state: "An endpoint MUST terminate the connection with error STREAM_STATE_ERROR if it receives a $FRAME frame for a locally initiated stream that has not yet been created, or for a $DIRECTION-only stream."
