Question:
Is this strictly necessary?
You're right, it's unnecessary and doesn't add anything. Removing via .

the method SHALL be "GET". <del> the request-target SHALL use absolute-form (see H1). </del> the request SHALL include a single Host header field containing the origin of the UDP proxy.


Question: PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al

contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527


Question: PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al

Payload field is longer than that limit without buffering the capsule contents. <ins> If a UDP proxy receives an HTTP Datagram before it has received the corresponding request, it SHALL either drop that HTTP Datagram silently or buffer it temporarily (on the order of a round trip) while awaiting the corresponding request. Note that buffering datagrams (either because the request was not yet received, or because the Context ID is not yet known) consumes resources.  Receivers that buffer datagrams SHOULD apply buffering limits in order to reduce the risk of resource exhaustion occuring. For example, receivers can limit the total number of buffered datagrams, or the cumulative size of buffered datagrams, on a per- stream, per-context, or per-connection basis. A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request and the UDP proxy chooses to not buffer them. </ins> 6. UDP proxies SHOULD strive to avoid increasing burstiness of UDP


Question:
This text was a mistake I made when converting from Datagram-Flow-Id to capsules.
Section 4 states that the proxy responds to a CONNECT-UDP request with 2xx and a corresponding registration capsule to indicate end-to-end support of datagrams. If the client sends a REGISTERDATAGRAMCONTEXT capsule, the corresponding capsule from the proxy will be of the same kind, and it will register a new server-generated context ID. So now we would have two context IDs for the same stream, which seems a bit unnecessary. Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT-UDP request is sufficient indication of end-to-end datagram support?
My reading of the spec is different, URL says So for example, if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID (0)}, the server will respond with REGISTERDATAGRAMCONTEXT { Context ID (0)} to confirm that the context is accepted.
That makes sense, I was assuming that the "used in both directions" referred to datagrams. I think my confusion in part came from the same section that says: But sending a registration capsule with an already registered context ID is not a new registration I suppose. Maybe it's good to clarify this a bit in the datagram spec. I'll open a separate issue there.
I agree the draft is a bit ambiguous here.
Indeed, the spec is unclear here, my apologies. I got this wrong when I rewrote the old Datagram-Flow-Id text. The server doesn't need to echo the registration capsule here since the client's registration is bidirectional. NAME we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations, is it required allowed forbidden I'm leaning towards (3) unless we have a use case for communicating the fact that a context is "accepted" and in which case I'd say (2).
Aha! In that case I apologise too. This seems important for interop! Now I remember, I think some people felt registration ack wasn't needed as long as there was a way to reject. And we have that with CLOSEDATAGRAMCONTEXT. So I think (3), modelled as implicit accept and explicit close, sounds good. That cuts down the chatter (and probably simplifies some code in my implementation).

consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds <del> to the CONNECT-UDP request with a 2xx (Successful) response, and indicates it supports HTTP Datagrams by sending the corresponding registration capsule. </del> <ins> to the CONNECT-UDP request with a 2xx (Successful) response. </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however


Question:
A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?

5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying


Question:
recovery (e.g., [QUIC]), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance as both can sometimes independently retransmit the same data. To avoid this, HTTP/3 datagrams SHOULD be used. This text could maybe be clearer. Is it trying to say "You SHOULD use H3 + Datagram" or "You SHOULD use H3 and if you do you should use datagram". I.e., is it possible to use H3 but not datagram?
You're right, this is unclear. That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams, so we should tweak it to say "To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame."

recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes <del> independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. </del> <ins> independently retransmit the same data.  To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame. </ins> 6.1.


Question:
This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream. <ins> HTTP/3 datagrams MUST only be sent with an association to a stream that supports semantics for HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP/3 datagrams cannot be sent associated with GET or POST request streams.  If an endpoint receives an HTTP/3 datagram associated with a method that has no known semantics for HTTP Datagrams, it MUST abort the corresponding stream with H3_GENERAL_PROTOCOL_ERROR.  Future extensions MAY remove these requirements if they define semantics for such HTTP Datagrams and negotiate mutual support. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP <del> Methods or new HTTP Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to- end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del> <ins> Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins> This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both


Question:
This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST


Question:
This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx <del> (Successful) status code.  The Capsule Protocol MUST NOT be used with messages that contain Content-Length or Transfer-Encoding header fields. </del> <ins> (Successful) status code. The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. </ins> 4.2. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del> <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> "Capsule-Protocol" is an Item Structured Header RFC8941.  Its value MUST be a Boolean.  Its ABNF is:


Question:
This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on


Question:
This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams. On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.
NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose. The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks

datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.


Question: In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> 1.


Question: In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> This document is structured as follows:


Question:
This is a good step but I think it overlooks one of the points that Magnus articulated. If an HTTP extension does what we say here, it might fall foul of intermediaries and protocol version conversion. That not some we have to solve but I suspect if we can concisely describe those considerations we would address the issue.
Good point, added text
Thanks, this is much clearer and is a descent explanation of the issues and motivation behind the should. I guess a more correct part will require much more text.
The first SHOULD should be a MUST because there is a clear exception specified but in all other cases this is a MUST. The second SHOULD should really be a MUST. Or why is that a SHOULD? If there is a reason for a SHOULD this needs to be explained but I think it would break interoperability.
I personally preferred MUST, however the consensus of the design team was SHOULD, and that was confirmed by the WG. Let's no reopen that unless we have new information.
On , NAME said:
I think the main motivation was that the MUST was unenforceable, and that there will be intermediaries that explicitly want to block unknown extensions for security reasons.
Whatever we might prefer, isn't this a case where whatever the specification says, intermediaries will do what they want?
I agree. That's why in the interest of making progress I'd rather move forward with the design team consensus instead of reopening this topic.
design team outputs don't have any special status here; perhaps the answer is not to say "SHOULD this" or "MUST that" but to instead articulate the intent behind the design and the potential consequences of not complying with that intent. Perhaps the key reason for mandating forwarding is that the meaning of various protocol elements is only valid in the context of all of the messages that an endpoint says. That is, you might send a bunch of datagram capsules that have meaning derived from other capsules. Remove the other capsules and you change the meaning of those datagram capsules. An intermediary that adds, modifies, or removes any capsules needs to understand the totality of the effect of their interventions. This is why I remain skeptical about the value of the generic capsule protocol. It only has value if it can be acted upon generically, but it is not obvious that it can be. Put differently, the existence of a generic capsule protocol implies a number of constraints on the operation of extensions that are not obvious and not clearly articulated. NAME might be asking about similar effects in .
So lets start with explaining the interoperability issue that is at the core of this: So the draft currently has several statements that interact with each other to cause this interoperability issue. Section 3.5 says: 'Note that use of the Capsule Protocol is not required to use HTTP Datagrams. If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.' Section 3.5 also says: 'An intermediary can reencode HTTP Datagrams as it forwards them. In other words, an intermediary MAY send a DATAGRAM capsule to forward an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa.' Thus the following may occur: Endpoint 1 sends a HTTP datagram as HTTP/3 Datagram over QUIC datagram. The HTTP intermediary re-encode this blind of its context to an Capsule Datagram and forward it to another HTTP intermediary that forwards it to an HTTP/3 endpoint using Datagram Capsule. As this HTTP datagram usage is one that does not require to support of Capsule Datagram this endpoint is not setup to handle this Datagram capsule and discards it. So this can either be fixed in various ways, not only what this issue text suggests: requiring the Datagram capsule support for all HTTP datagram handling nodes. In other words change the first quote. Require the HTTP intermediary to re-encode any Datagram capsules to HTTP/3 datagram if the next hop is know to support it. i.e. make additional requirements on how HTTP Intermediaries act when forwarding. Forbid blind forwarding of HTTP datagram in HTTP intermediaries. I think we should settle this part before going back to see how the text Mirja suggested changing matter. I think 1 and 2 are both working solutions, and would like to avoid 3. I think there is also a question on the implication of what it means to support HTTP datagram when one is an HTTP/3 endpoint or intermediary. Who is expected to support the Datagram capsule if the next node is not capable? So I think at the bottom this issue is really the question about the possibility to convert between HTTP/3 Datagram and Datagram capsule. I think we need to settle that question first. It is a question of what requirements one have on endpoints vs intermediaries. Lets start in that end.
I actually think I prefer your option 3, caveated by saying "if you're an intermediary and you don't know the upgrade token, don't insert datagram capsules" . What concern do you have about option 3?
Okay, I am skeptical against 3) on how it may make deployment of future extensions that require HTTP Datagram but doesn't need other than Intermediary forwarding. In that case deployment could be hampered if not all HTTP intermediaries are also HTTP/3 capable. It appears that using capsule protocol would be easier to enable over a legacy system. That might be a misconception from my part.
NAME Thank you for clarifying, now I understand where the disconnect is. The draft currently says and you interpreted that as but that's not what we intended, we meant . I've written up to remedy this
NAME great that we managed to sort out what was the issue. As Lucas noted in the PR unless all HTTP Datagram implementation support and accept receiving Datagram capsule, even if not intended by the HTTP Extension, if unaware of HTTP extension transformation is allowed, it can fail. I think we need a bit more feedback on where people stand in this aspect.
Thanks NAME If the HTTP extension doesn't use capsules, then the implementation won't parse the data stream as capsules so there is no risk of accidentally receiving capsules. We added text to to clarify the risks of not using the capsule protocol.
I think this was closed prematurely because the issue originally was about MUST or SHOULD and I don't think we concluded on this. If the argument is that this is not enforceable, I think we should not use normatively language at all (and say something like "intermediaries are expected ..."). However, using SHOULD were we actually mean MUST, weakens the requirement and risk that this is misunderstood to be optional (while I think this is the core of the whole capsule protocol).
Reopening to discuss SHOULD vs MUST.
I'd consider capsules to be similar to header fields (headers specifically, not trailers). Here's what HTTP says about them in URL >A proxy MUST forward unrecognized header fields unless the field name is listed in the header field () or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header and trailer fields. Adhering to these requirements allows HTTP's functionality to be extended without updating or removing deployed intermediaries. Yeah, in actuality an intermediary can do lots of stuff, and in practice they do. But if a MUST is good enough for HTTP headers, why isn't it here?
From memory it was either NAME or NAME who cared strongly about this not being a MUST. I'm fine either way as long as we don't drag this one needlessly.
To summarize the discussion on this issue up to this point: we're debating whether to tell intermediaries that they MUST or SHOULD forward unknown capsules unmodified implementors of intermediaries will not react to either one of these words differently endpoints have no way of enforcing this MUST some folks felt very strongly against MUST the working group landed on this design and no new information has surfaced since Based on the points above, there is no reason to hold up document progress based on a single word that will not have any impact. Therefore I'm closing this issue with no action. Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric

large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.


Question: As discussed at IETF 110, some MASQUE servers may prefer to avoid sticking out (i.e. they may wish to be indistinguishable from a non-MASQUE-capable HTTP/3 server). The H3_DATAGRAM SETTINGS parameter may stick out. Therefore, we should add a note about this to the Security Considerations section. A simple solution could be to encourage widespread HTTP/3 servers to always send this.

8. <del> This document does not have additional security considerations beyond those defined in QUIC and DGRAM. </del> <ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this feature SHOULD always send this Settings parameter to avoid leaking the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. </ins> 9.


Question:
This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given <del> QUIC stream.  Second, datagrams carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </del> <ins> QUIC stream.  Second, datagrams optionally carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </ins> contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end.


Question:
This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> Contexts are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </del> <ins> Contexts are optional, their use is negotiated on each request stream using registration capsules, see register-capsule and register-no- context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more


Question:
This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


Question:
This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream before they have received at least one REGISTER_DATAGRAM_CONTEXT <del> capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a </del> <ins> capsule or one REGISTER_DATAGRAM_NO_CONTEXT capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream where it has received a REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a </ins> client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where <del> the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the </del> <ins> the client has sent a REGISTER_DATAGRAM_NO_CONTEXT capsule, the </ins> client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.2. <ins> The REGISTER_DATAGRAM_NO_CONTEXT capsule (type=0x03) allows a client to inform the server that datagram contexts will not be used with this stream.  It also informs the server of the encoding and semantics of datagrams associated with this stream.  Its Capsule Data field consists of: A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the datagrams it sends and receives with this stream. Endpoints MUST NOT send DATAGRAM frames without a Context ID until they have either sent or received a REGISTER_DATAGRAM_NO_CONTEXT Capsule.  However, due to reordering, an endpoint that receives a DATAGRAM frame before receiving either a REGISTER_DATAGRAM_CONTEXT capsule or a REGISTER_DATAGRAM_NO_CONTEXT capsule MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting a REGISTER_DATAGRAM_NO_CONTEXT capsule or the corresponding REGISTER_DATAGRAM_CONTEXT capsule. Servers MUST NOT send the REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a client receives a REGISTER_DATAGRAM_NO_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send more than one REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream.  If a server receives a second REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server 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. Clients MUST NOT send both REGISTER_DATAGRAM_CONTEXT capsules and REGISTER_DATAGRAM_NO_CONTEXT capsules on the same stream.  If a server receives both a REGISTER_DATAGRAM_CONTEXT capsule and a REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given context ID.  Its Capsule Data field


Question:
This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.

MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.3. </del> <ins> 4.4. </ins> The DATAGRAM capsule (type=0x02) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when