Change:
Explicitly replicates parts of H2 and H3 CONNECT stream definition to make it clear what frame types are/are not allowed on a stream. Mostly anything else can't happen but if it does, approach error handling as if it were like a malformed message (I.e whether to terminate the stream or whatever).
Found it and fixed, thanks Martin!
In Sec 3.3: When an error occurs in processing the Capsule Protocol, the receiver MUST treat the message as malformed or incomplete... there are 2 other reference to malformed "messages" as a result of Capsule shenanigans. but in the introduction it says that datagrams "are not part of message content". So what is "the message" that should be treated this way? I think you mean the Request or Response that initiated the Capsule protocol. If that's correct, a more precise phrasing might be "MUST act as if the message that initiated the capsule protocol was malformed".
Agree we can probably tighten things up here. For one, the definition of "data stream" in 3.1 presently says In isolation, this statement leaves it a little unclear whether trailing headers can appear after the data stream. In , that defines how CONNECT works, things are a lot clearer: My working assumption has been that data streams have similar requirements, but we don't explicitly state that anywhere, which is not great. If we tighten that up then it should become clearer that, once the capsule protocol is successfully negotiated, the HTTP message ended after the first HEADERS frames. We would still expect endpoints to apply some rules to frame processing on these data streams, and if there was a problem the data stream is malformed. Today we equate malformed data streams to malformed requests, and therefore delegate the handling of such problems (reset stream + error code) to the respect section in H2 or H3. I wonder actually if we should just state some explicit stream termination requirements. This does not change the actions that endpoint might take, but it does clarify the circumstances under which they should happen. I'll prepare a PR for this to help illustrate my thinking. To summarise: 1) If an endpoint screws up meeting the requirements of request or response field sections that bootstrap a capsule protocol instance, that is clearly a standard "malformed message" 2) If, after a capsule protocol instance has successully been created, an endpoint screws up anything on the data stream, that does not seem like a "malformed message"
I can understand the impulse to avoid the term "stream" because then you're in the business of defining the behavior per HTTP version, but I'm sure you'll come up with some good language.
+1 to what Lucas said above

Discussion:
and response do not carry HTTP content.  A future extension MAY define a new capsule type to carry HTTP content. <ins> Since the Capsule Protocol only applies to definitions of new HTTP Upgrade Tokens, in HTTP/2 and HTTP/3 it can only be used with the CONNECT method.  Therefore, once both endpoints agree to use the Capsule Protocol, the frame usage requirements of the stream change as specified in H2 and H3. </ins> The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset

3.3. <del> When an error occurs in processing the Capsule Protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed </del> <ins> When a receiver encounters an error processing the Capsule Protocol, the receiver MUST treat it as if it had received a malformed or incomplete HTTP message.  For HTTP/3, the handling of malformed </ins> messages is described in H3.  For HTTP/2, the handling of malformed messages is described in H2.  For HTTP/1.1, the handling of incomplete messages is described in H1.

Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes after the identified fields or a capsule payload that terminates <del> before the end of the identified fields MUST be treated as a malformed or incomplete message.  In particular, redundant length </del> <ins> before the end of the identified fields MUST be treated as it if were a malformed or incomplete message.  In particular, redundant length </ins> encodings MUST be verified to be self-consistent. If the receive side of a stream carrying capsules is terminated cleanly (for example, in HTTP/3 this is defined as receiving a QUIC STREAM frame with the FIN bit set) and the last capsule on the stream <del> was truncated, this MUST be treated as a malformed or incomplete message. </del> <ins> was truncated, this MUST be treated as if it were a malformed or incomplete message. </ins> 3.4.