Change:
initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. <ins> 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. </ins> 4.1. The REGISTER_DATAGRAM_CONTEXT capsule (type=0x00) allows an endpoint

Discussion:
This makes the requirement global to clients, servers, and intermediaries.
NAME 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 URL H3GENERALPROTOCOLERROR is to be used when a more specific error code isn'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 Capsule 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 can'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 isn't always easy so I don't think we can mandate it. I honestly don'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) Client HEADERS Server HEADERS, Server CAPSULE (registerdatagramcontext) So is this sequence Client HEADERS Client CAPSULE (registerdatagramnocontext) Client CAPSULE (registerdatagramnocontext) From what the spec says, I'm less clear on if this sequence is illegal Client HEADERS Client CAPSULE (datagram) Client 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 can'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 doesn'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 can'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] - URL
I'm not sure what you're suggesting in terms of changes to the draft NAME could you elaborate?

The specific suggestion in this case is, disallow intermediaries from sending datagram capsules before register capsules. This might make Alan 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 didn'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?