Change:
field or adhere to the requirements leveraged by that method on intermediaries. <ins> If an intermediary processes distinct HTTP requests that refer to the same flow identifier in their respective "Datagram-Flow-Id" header fields, it MUST ensure that those requests are routed to the same backend. </ins> 8. This document does not have additional security considerations beyond

Discussion:
This PR switches the header to a list on MT's suggestion to make the semantics clearer.
URL states: The text is a little ambiguous. I presume the intention is that the endpoint that is allocating flows should do what HTTP/3 defines as ? The doesn't cover the case where an endpoint receives a Datagram Flow ID greater than 10^15-1 (either in a request or a DATAGRAM). I think it might help to separate these cases. Receiving a value of 10^15-1 is always a connection error of type H3IDERROR. But I'm not so sure about the sender case, if you really are flow ID exhausted, perhaps it is nicer to just spin up a new connection and leave the current one as is. We might recommend that endpoints initiate an HTTP/3 graceful close followed by an application close - but reusing H3IDERROR for that case seems a bit overkill.
I don't think receiving a DATAGRAM whose flow ID is >= 10^15 is an error, the receiver should just silently drop it as the flow ID is unknown. Either way we should add text to clarify the expected action of the receiver. In the sender case, I agree with you when the sender is the client, because in that case the client should instead just spin up a separate connection. On the server sender however, there is no such escape hatch, so perhaps we should tell the server to fail the operation that requested the flow ID.
Sorry I was not specific in my comment. I meant to speak about receiving the header field e.g. That would lead to an SF Integer parsing error, which would cause the field to be ignored - unless we define different behaviour. Ignoring the header has an interesting interplay with the optional guidance to buffer it until they receive the "Datagram-Flow-Id" header. Ignoring things that are strictly above the known limits seems a little too generous. Is there a reason not to reject such requests and HTTP/3 DATAGRAMS?
Ah, in that case I agree - receipt of a Datagram-Flow-Id header with value >= 10^15 should cause a connection error of type H3IDERROR.

I was just thinking that conceptually receiving DATAGRAM with strange flow IDs should not be an error because that might lead implementors to declare than any unknown flow ID is an error which would break valid scenarios in the presence of reordering.
Yeah. However, I think it would be fine to reject such a request with an 4xx response rather than tear down the entire connection...
Fair enough, that works too. I'll just state that in that scenario the request is malformed
Section 6 makes the keen observation that: This is accurate but, when thinking about HTTP/3 APIs, does not cover all possible reasons that might cause a request message to be processed after the corresponding DATAGRAM frame is available. For instance, the message might be blocked by QPACK, or the implementation might present DATAGRAMS before stream headers. We could boil the ocean with describing all possible reasons, so I think it might be better to shuffle the text to focus on describe the symptom (DATAGRAMS before HTTP messages) and the treatment. We can then give non-exhaustive example(s) as already done.
I would prefer to not boil the ocean :) I'll make an editorial change to make it clearer that this is just an example among others.
The document currently uses the following example: Motivating this with an example of how to express multiple flow identifiers. I think that this example is potentially harmful. It implies a lot about a potential extension mechanism as part of an example, but does not commit to properly defining an extension. For examples like this I would much prefer to see something that is very clearly bogus. Otherwise, people might implement that to the point that they even achieve interoperability of a sort. For instance, the following requires a lot more guessing about how to interpret it, to the point that I would guess that pseudo-interoperability would be hard to arrive at by accident: See also .
The goal of this example was to show a way to build an extension. A full example of this being used is . I'm not really sure how to improve this, because making it clearly bogus defeats the purpose. Could you provide a PR?
Maybe we should talk more about the spelling of the ECN extension, which I haven't reviewed. I don't think that you should hide flow identifiers in this fashion.

It prevents an intermediary from understanding which requests are actively using flow identifiers. A gateway might need to know that in order to ensure that DATAGRAM frames are consistently forwarded to the right origin server. An alternative spelling that doesn't have that property would be:
To make sure I'm understand you correctly, are you suggesting a structured field list here? That would work, and actually in that case I'd suggest dropping the parameter on the first element to make this simpler.
Yep, that's it. And I considered the same. No parameter works fine.
It's not really clear whether there are any expectations in relation to cardinality of flow identifiers and the field. Can two fields refer to the same flow ID? Can the same request reference multiple flow IDs?
I think the h3 datagram draft should allow both: two requests can reuse the same flow ID if the definition of that HTTP features allows it (this feature is used by the ) one request can reference two flow IDs - I think this is already stated though:
I'm sure that people operating intermediaries might have something to say here. A gateway that routes flows might be unwilling to replicate datagram flows that are bound to requests that go to different origin servers. I agree that one request to many flows is worthwhile, but mention in examples doesn't really count as a specification.
Fair enough, I'll add text to make this clearer. And I'll add a note to the intermediaries section about how the intermediary needs to ensure that if a second request arrives that shares a flow ID with a previous one, the intermediary MUST either send the new request to the same backend or reject it.