Draft: draft-ietf-masque-h3-datagram

Commentary: 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 ca n'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  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 do n'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
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.
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
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.
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
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
before the end of the identified fields MUST be treated as a
malformed or incomplete message.  In particular, redundant length
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
was truncated, this MUST be treated as a malformed or incomplete
message.
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
before the end of the identified fields MUST be treated as it if were
a malformed or incomplete message.  In particular, redundant length
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
was truncated, this MUST be treated as if it were a malformed or
incomplete message.