Original text:
6.  We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3. <del> 7. </del>  Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 8. </del>  <del> 8.1. </del>  This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: <del> 8.2. </del>  This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 8.3. </del>  This document establishes a registry for HTTP/3 frame type codes. The "HTTP Capsule Types" registry governs a 62-bit space. This registry initially contains the following entries: <del> 8.4. </del>  REGISTER_DATAGRAM_CONTEXT capsules carry key-value pairs, see register-capsule.  This document will request IANA to create an "HTTP Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Key.  This registry is initially empty. <del> 9.  References </del>  <del> 9.1.  URIs </del>  [1] mailto:masque@ietf.org

Reviewer comments:
Punt prioritization to extensions like QUIC and HTTP/3 did.
I think it's be valuable for h3-datagram to be able to use the new HTTP priority draft. I think it'd be ok to say that the datagram flow has the same prioritization as the request that initiated it. I don't think anything more complex is necessary, but I could be wrong.
That seems reasonable to me, assuming that we can get some implementations of this first. I suspect that we'll want this text to live in whichever gets published last between draft-ietf-masque-h3-datagram and .
The extensible priorities draft doesn't prioritise streams, it prioritizes responses. Is it sufficient that only a client can control the relative priority of datagrams coming back to it?
oh and FWIW as an editor on priorities, we are pretty close to a WGLC. If there's merit in saying something about datagrams and priorities, putting it here feels like the right thing.
Given the client already has the ability to control the relative priority of datagrams its sending, I think that's ok? Possibly there are use cases where the server wants to indicate a priority to the client as well? My strawman use case is tunneling multiple HTTP/3 connections: One goes to the origin, one goes to a static content server, ads, etc, and the client wants to receive data from the origin at a higher priority than the other data.
I think that is a good use case! I don't know if someone will turn around and say they really want to support that server control use case, I'm keen to hear strong proponents to really understand why. Making DATAGRAM priority based on streams aids parity between CONNECT and CONNECT-UDP cases. To your mind, would datagrams be prioritized against other datagrams and other streams? There's probably something to say here, especially the edge case where there is data to be sent non-incrementally on the stream AND the datagram flow. Something to consider is also that if we go ahead with a 2-layer approach, whether we want to expose per-flow priorities. Maybe that can be done by carrying the extensible priority value as an extension field in the flow creation message. Although it does sound a bit too much complexity.
I really hope we can avoid that, since it means the proxy/intermediary would have to deal with subflows, whereas currently it doesn't have to. Also, for most of the subflow use cases I've heard, I don't think that would be valuable or necessary.
Agree about the context/subflows things. Lets avoid that. For the bigger picture stuff I'd need to think on this some more. Perhaps a mildly flexible solution is to define an extensible priorities extension that would 1) explain some of the considerations into scheduling relative priorities between streams and datagrams 2) define a parameter to allow explicit setting of datagram flow priority. For example, to have an incremental stream at urgency 1 and incremental datagram at urgency 3 We could then state that omitting the parameter means the stream's priority is used. 3) by adding more params to we could even support explicit signalling of the wish for shared priority space, or segregated.
I'd say that defining a new prioritization parameter should be left to its own document, I'd prefer not to have this in h3-datagram itself
I agree its scope creep. I would be ok with this document saying very little and punting the problem to a (which I would entertain co-writing)
I think defining priorities of sub-flows would be useful in Ian's use case if you wanted to merge the priorities of streams within the tunneled QUIC connections at the entry proxy, rather that strictly prioritize one tunnel over another. One could do this by registering a context-ID for each priority level. This context-ID could be used by the intermediary (did I break the rules again?) to determine the priority of the datagram back towards the client.
I'm going to propose closing this issue with no action, with the intent to leave this functionality to extensions.
Adding text that says by default datagrams inherit the priority of the stream they are associated with seems likely to capture the most common cases. If we can't agree on that and want to punt, it would be good to indicate in the draft that priority of datagrams is undefined/implementation specific.
I'll would be happy with Alan's suggestion. I will prepare a PR unless someone beats me too it. Edit: suggestion to state that it is undefined
NAME stating that it is undefined sounds great to me.
I prefer it inherit the priority of the associated stream as NAME suggested.
I think that sounds like an easy suggestion but in practice doesn't help implementers. Inheriting the same signal doesn't really help the multiplexing scheduling conundrum - IMO trying to make any reasonable suggestion will tie up time in this document development that could be answered elsewhere.
If I'm an intermediary l7 load balancer, and support h3-datagram but am not looking deeper into the payload, I'm going to have to make scheduling decisions, so leaving it undefined could cause large differences in how h3-datagram based applications work on different intermediaries.
Right but that's the situation the base HTTP/3 specification has right now too. And even if the L7 balancer applies scheduling logic based on the extensible priorities draft, 1) it would need to decide how to schedule ingress data (request content) itself, since that is not defined 2) we have little experience about how to schedule datagram and stream data concurrently. I would expect implementers to turn around immediately and ask us how to do that if we say explicitly here that there is a datagram priority signal. I am not saying we punt the question indefinately. But in the interest of making progress here (especially to limit feature creep) I am suggesting we write a standalone document that can capture all the concerns as completely as is useful. If that draft makes rapid progress it might be a candidate for getting incorporated back into the H3 datagram specification. I would be happy to bootstrap that document in a new repo and work with Alan, Ian or other folks that can give some opinions.
+1 to NAME The more I think about this the more I believe that H3DGRAM has to match what H3 does - in a vacuum as an implementor I don't know how to implement "datagram should inherit priority of the corresponding stream" when no one has actually defined what a priority is. There are important questions like "should higher priority completely starve lower priority or not?" that are not answered by H3. H3DGRAM itself cannot depend on a given priorities extension, because we might define a different priorities scheme later. Having a separate draft that explains how to combine draft-ietf-masque-h3-datagram and draft-ietf-httpbis-priority sounds like the best option.

Revised text:
6. <ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their prioritization preferences. 7. </ins> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3.  <ins> 8. </ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a the fact that there are applications using HTTP/3 datagrams enabled on this endpoint.  <ins> 9. </ins>  <ins> 9.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Frames" registry:  <ins> 9.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  <ins> 9.3. </ins> This document establishes a registry for HTTP/3 frame type codes. The "HTTP Capsule Types" registry governs a 62-bit space. This registry initially contains the following entries:  <ins> 9.4. </ins> REGISTER_DATAGRAM_CONTEXT capsules carry key-value pairs, see register-capsule.  This document will request IANA to create an "HTTP Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Key.  This registry is initially empty.  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] mailto:masque@ietf.org