Draft: draft-ietf-masque-h3-datagram

Commentary: This makes the requirement global to clients , servers , and intermediaries . 
 does the PR address your issue ? 
 merging , please reopen the ticket if you need anything more 
 The HTTP/3 RFC states The current draft instead recommends closing the stream rather than the connection and with the generic H3GENERALPROTOCOLERROR According to H3GENERALPROTOCOLERROR is to be used when a more specific error code is n't available , but here we have clearly a more specific error available . Also , what is the rationale for closing just the stream and not the whole connection ? Furthermore , a more general question : right now the above recommendation only exists for REGISTERDATAGRAMNOCONTEXT and REGISTERDATAGRAM_CONTEXT capsule types . Would it be fair to say that no  frame is allowed before headers instead ? 
 Thanks . I think it would be for us to clarify a ) strict ordering rules of capsule amongst HTTP message frames . b ) strict ordering rules of capsule types . For ( a ) , I 'm inclined to state a top - level requirement that CAPSULE frames MUST NOT arrive before the first HEADERS on a request stream . Violation of that is connection error of type H3FRAMEUNEXPECTED . For ( b ) , I 'm slightly less sure . We clearly have some ordering requirements . The H3 base spec treats misordering as a critical failure . We treat it here as a stream error . I think we could make things more similar to H3 . For instance , I ca n't think of a good reason right now why we are so loose with handling of datagram capsules ; if they arrive on a stream before a register capsule , that smells broken . 
 Banning all capsules before headers sounds reasonable to me . Strict ordering of capsules is required on the sender , but enforcing that on the receiver is n't always easy so I do n't think we can mandate it . I honestly do n't care if it 's a stream or connection error , either works for me . 
 Happy to write the PR for this . Right now I 'm thinking we cam make ( b ) a more specific error code too . I think H3FRAMEUNEXPECTED is good enough for capsule types but we could always define a H3CAPSULE UNEXPECTED is people felt strongly . 
 Do you have an example of where ( b ) is useful ? In other words , what 's a sequence of events that leads a receiver to detect a capsule illegal ordering ? 
 The following sequence is legal by ( a ) but illegal by ( b ) HEADERS HEADERS , CAPSULE ( registerdatagramcontext ) So is this sequence HEADERS CAPSULE ( registerdatagramnocontext ) CAPSULE ( registerdatagramnocontext ) From what the spec says , I 'm less clear on if this sequence is illegal HEADERS CAPSULE ( datagram ) CAPSULE ( registerdatagramno_context ) There 's a lot of text about DATAGRAM frames and ordering . But when sending Datagram capsules on streams , they can be strictly ordered on sender and receiver . H3 treats such ordering as specific problem because it is avoidable . 
 That last sequence probably ca n't be illegal , since it is possible when forwarding through an intermediary with and without datagram support . Eg : Client < -Intermediary supports native datagram and Intermediary < -Server only supports datagram CAPSULE . Since the intermediary only needs to forward and not inspect , the datagram CAPSULE can arrive before the registerdatagramno_context CAPSULE . 
 That 's what I thought initially , but the spec presently says By my read , an intermediary that receives a DATAGRAM frame and wants to convert it to a capsule needs to wait for the register capsule . 
 The spec does n't define endpoint . Is an intermediary an endpoint ? 
 Need to nail that down . Having different sending rules for clients and " intermediary doing client behaviour " is a recipe for illness , the server ca n't know what the sender thinks it is . 
 An endpoint is the opposite of an intermediary . If that 's not obvious then we should spell it out in the draft . Intermediaries do not parse register capsules . 
 I think the parsing stuff is clear . What 's a bit unclear is the message forwarding requirements . The HTTP definition [ 1 ] of intermediary allows some variance . In the gateway case , it 's stated that third - party HTTP servers needs to conform to user agent requirements on the gateway 's inbound connection . Allowing deviation is permitted but might cause interop problems . [ 1 ] - 
 I 'm not sure what you 're suggesting in terms of changes to the draft could you elaborate ? 
 The specific suggestion in this case is , disallow intermediaries from sending datagram capsules before register capsules . This might make  sad because an intermediary would need to buffer DATAGRAM frames and only forward them as capsules once a register is seen . Note that it would not require the intermediary to act on the register capsule , just enforce sequencing rules between datagrams and streams 
 I 'd rather we did n't add that suggestion . It increases complexity for intermediaries and I 'm not sure what problem it solves ? 
 That 's fine . I 'd be happy with not adding that . However , to make it clear what the spec is allowing , we should make a note in Section 4.4 that the ordering / buffering requirements of DATGRAM frames and register capsules ( from sec 3 ) do not apply to intermediaries when forwarding . That 's tangential to Luca 's OP so we can spin it off separately . 
 I agree , that sounds like a good resolution . Can you file an issue please ?
CAPSULE frames MUST NOT be sent on a stream before at least one
HEADERS frame has been sent on that stream.  This removes the need to
buffer capsules when the endpoint needs information from headers to
determine how to react to the capsule.  If a CAPSULE frame is
received on a stream before a HEADERS frame, the receiver MUST treat
this as a connection error of type H3_FRAME_UNEXPECTED.
Endpoints MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a
stream before they have sent at least one HEADERS frame on that
stream.  This removes the need to buffer REGISTER_DATAGRAM_CONTEXT
capsules when the endpoint needs information from headers to
determine how to react to the capsule.  If an endpoint receives a
REGISTER_DATAGRAM_CONTEXT capsule on a stream that hasn't yet
received a HEADERS frame, the endpoint MUST abruptly terminate the
corresponding stream with a stream error of type
H3_GENERAL_PROTOCOL_ERROR.
Clients MUST NOT send a REGISTER_DATAGRAM_NO_CONTEXT capsule on a
stream before they have sent at least one HEADERS frame on that
stream.  This removes the need to buffer REGISTER_DATAGRAM_CONTEXT
capsules when the server needs information from headers to determine
how to react to the capsule.  If a server receives a
REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream that hasn't yet
received a HEADERS frame, the server MUST abruptly terminate the
corresponding stream with a stream error of type
H3_GENERAL_PROTOCOL_ERROR.