Draft: rfc9114

Commentary: observed a seeming conflict in the requirements around unknown unidirectional stream types . Section 9 says : This has two problems . First and editorial , if the type is unknown / unsupported , the presence of frames ca n't be determined . This should refer to discarding any data , not frames specifically . Second , it appears to disagree with Section 6.2 : I think the intent was MUST abort , but MAY pick an error code . Looking at the history of the commits in Section 6.2 , it was first MUST abort , then SHOULD use a particular code , then became MAY use the specific code with the prohibition on blowing up the whole connection . The text should clarify the scope of the MAY . 
 Agree . This change would meet the intent of the text and is editorial . So it the proposal here something like : 
 I think I 'd say " MUST either abort reading of the stream or discard incoming data without further processing . If reading is aborted , the recipient SHOULD use .... " 
 That would work for me too , care to make a PR ? 
 Closed in . 
 LGTM thank you
Paragraph (version A):
If the stream header indicates a stream type that is not supported by
the recipient, the remainder of the stream cannot be consumed as the
semantics are unknown.  Recipients of unknown stream types MAY abort
reading of the stream with an error code of H3_STREAM_CREATION_ERROR
or a reserved error code (http-error-codes), but the recipients MUST
NOT consider such streams to be a connection error of any kind.
Paragraph (version B):
If the stream header indicates a stream type that is not supported by
the recipient, the remainder of the stream cannot be consumed as the
semantics are unknown.  Recipients of unknown stream types MUST
either abort reading of the stream or discard incoming data without
further processing.  If reading is aborted, the recipient SHOULD use
the H3_STREAM_CREATION_ERROR error code or a reserved error code
(http-error-codes).  The recipient MUST NOT consider unknown stream
types to be a connection error of any kind.
Paragraph (version A):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard frames
and abort reading on unidirectional streams that have unknown or
unsupported types.  This means that any of these extension points can
be safely used by extensions without prior arrangement or
negotiation.  However, where a known frame type is required to be in
a specific location, such as the SETTINGS frame as the first frame of
the control stream (see control-streams), an unknown frame type does
not satisfy that requirement and SHOULD be treated as an error.
Paragraph (version B):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard data or
abort reading on unidirectional streams that have unknown or
unsupported types.  This means that any of these extension points can
be safely used by extensions without prior arrangement or
negotiation.  However, where a known frame type is required to be in
a specific location, such as the SETTINGS frame as the first frame of
the control stream (see control-streams), an unknown frame type does
not satisfy that requirement and SHOULD be treated as an error.