jiebi/CodeConvo huggingface dataset:
Change:
Borrowing text from H3. Also I don't think there is a 'FRAMEENCODINGERROR' defined anywhere.
Thanks! Approved pending some minor tweaks

Discussion:
-1, so the largest legal value of Quarter Stream ID is 2 -1.  Receipt of a frame that includes a larger value MUST be <del> treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> treated as a connection error of type H3_DATAGRAM_ERROR. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 <del> connection error of type H3_GENERAL_PROTOCOL_ERROR. </del> <ins> connection error of type H3_DATAGRAM_ERROR. </ins> Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding stream's send side is open.  On a given endpoint, once the receive

4.2. <ins> When an error occurs processing the capsule protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed messages is described in section 4.1.3 of H3.  For HTTP/2, the handling of malformed messages is described in section 8.1.2.6 of H2. For HTTP/1.1, the handling of incomplete messages is described in section 8 of CORE-MESSAGING. Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes after the identified fields or a capsule payload that terminates before the end of the identified fields MUST be treated as a malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent. When a stream carrying capsules terminates cleanly, if the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. 4.3. </ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing.

Protocol header field value, but future documents MAY define parameters.  Receivers MUST ignore unknown parameters. <del> 4.3. </del> <ins> 4.4. </ins> This document defines the DATAGRAM capsule type (see iana-types for the value of the capsule type).  This capsule allows an endpoint to

8.2. This document will request IANA to register the following entry in <ins> the "HTTP/3 Error Code" registry: 8.3. This document will request IANA to register the following entry in </ins> the "HTTP Field Name" registry: Capsule-Protocol

None <del> 8.3. </del> <ins> 8.4. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.
Change:
Why would parentheses be required? Exponent has higher precedence than subtraction.
I think this proposal resolves the misinterpretation of 2^62 - (1/4)
Oh my bad, I had misread.

Discussion:
streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 <del> -1, so the largest legal value of Quarter Stream ID is 2 </del> <ins> -1, so the largest legal value of Quarter Stream ID is (2 </ins> <del> -1 / 4.  Receipt of a frame that includes a larger value MUST be </del> <ins> -1) / 4.  Receipt of a frame that includes a larger value MUST be </ins> treated as a connection error of type FRAME_ENCODING_ERROR. A variable-length integer indicating the context ID of the
Change:
cc NAME
I think that this is right, but we should be more precise about what this means. That is, if the method is CONNECT and either: the intermediary understands the :protocol selection, or the request includes Capsule-Protocol Then the intermediary can forward DATAGRAM capsules as QUIC DATAGRAM frames or forward QUIC DATAGRAM frames as DATAGRAM capsules. Those conditions could be spelled out more clearly.
I agree. I'll add this to the . Note that this was filed on the wrong repository, is the droid you're looking for.
Oops. You should be able to move the issue.
Ah right, thanks! I've moved the issue.

Discussion:
Capsules MUST be forwarded unmodified by intermediaries, with the exception of the DATAGRAM capsule; see datagram-capsule.  An <del> intermediary that understands the request semantics enough to know that capsules are in use MAY convert between QUIC DATAGRAM frames and DATAGRAM capsules.  Definitions of new Capsule Types MAY specify optional custom intermediary processing. </del> <ins> intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by understanding the chosen HTTP Upgrade token.  An intermediary that identifies the use of the capsule protocol MAY convert between DATAGRAM capsules and QUIC DATAGRAM frames when forwarding. Definitions of new Capsule Types MAY specify optional custom intermediary processing. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule.
Change:
The doc has evolved from just HTTP/3 Datagram, to define Capsule protocol and HTTP datagrams over capsule. In Security Considerations, we say It's a little ambiguous what "this feature" on face value. Arguably, the recommendation to always send the setting could be done in the section that defines the setting. Some editorial work would address these concerns.
Agreed
The intent is much clearer to me now, thanks!

Discussion:
the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. <ins> It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. </ins> 5.1. [[RFC editor: please remove this section before publication.]]

7. <del> 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. </del> <ins> Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. </ins> 8.
Change:
The HTTP/3 spec was "contracted out to the QUIC WG", but the registries it establishes are given back to the the HTTP WG are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (EMAIL). This spec defines some new registries, it isn't clear to me which WG would "own" the registry after we are done with this spec.
Technically, IANA registries aren't owned by Working Groups. But adding the HTTP working group as a contact for the initial entries sounds fine by me. But I'd prefer to put this on hold until we're closer to publication.
WFM!

Discussion:
This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <ins> 0xffd277 (note that this will switch to a lower value before publication) H3_DATAGRAM 0 provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </ins> 8.2. This document will request IANA to register the following entry in
Change:
In we discussed the risk presented by buffering extremely large datagram capsules. We should add some text to warn about this.
lgtm modulo nit

Discussion:
large without suffering any loss; this can misrepresent the true path properties, defeating methods such as DPLPMTUD. <ins> While DATAGRAM capsules can theoretically carry a payload of length 2 -1, most applications will have their own limits on what datagran payload sizes are practical.  Implementations SHOULD take those limits into account when parsing DATAGRAM capsules: if an incoming DATAGRAM capsule has a length that is known to be so large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. </ins> 5. Implementations of HTTP/3 that support HTTP Datagrams can indicate
Change:
We say: This has some parallels to Extensible Priorities where we are expected to handling an H3 frame that might reference a stream that has not yet been created (most likely due to reordering). We can't avoid reordering but we can be more conservative on the frames that do get buffered. URL says: We can probably recommend something similar here.
This makes sense, sending an HTTP Datagram for a stream that you're not yet allowed to create violates a MUST in a detectable way so we can recommend punishment. Though I doubt that we'd implement this check.

Discussion:
that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream. <ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that cannot be created due to client-initiated bidirectional stream limits, it SHOULD be treated as a connection error of type H3_ID_ERROR.  Generating an error is not mandatory in this case because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </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
Change:
The HTTP WG is working on a style guide, see URL In line with the style, the reference to structured fields is updated in because it's less contentious. What remains here is probably more so. First, move the consideration for intermediaries to the bottom of the section. It doesn't seem a leading item to me. Then we start the section with a focus on defining the field itself. The ABNF is probably the bit we'll disagree with. It seems in trying to be specific on the Item type, you've written out the the subcomponents of the ABNF. This is something that is being discussed in the HTTP WG list. Personally I don't like being overly specific in the ABNF because it could be misconstrued as something that is SF-like but not really SF. As far as a generic SF parser goes, it will only validate that the thing is an Item and it will be up to higher layers to apply additional constraints on that. Parameters can always appear with an Item on the wire, whether an application allows that or not is a different matter. Restating ABNF makes this topic more thorny.

Discussion:
4.3. <del> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. "Capsule-Protocol" is an Item Structured Header (see STRUCTURED- FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </del> <ins> This document defines the "Capsule-Protocol" header field.  It is an Item Structured Header RFC8941; its value MUST be a Boolean.  Its ABNF is: </ins> Endpoints indicate that the Capsule Protocol is in use on the data stream by sending the Capsule-Protocol header field with a value of

Protocol header field value, but future documents MAY define parameters.  Receivers MUST ignore unknown parameters. <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> 4.4. This document defines the DATAGRAM capsule type (see iana-types for
Change:
The text of the draft currently defines how the header works, but there's no RFC 2119 text explaining whether the client MUST or MAY send it (and the corresponding receiver behavior in case the header is missing).
The draft currently states - right now it's up to CONNECT-UDP / WebTransport, etc to define this normative text. Is that acceptable?
Sure, but it's not clear from the current text that the drafts have to give the specific guidance about the use of the header (the WebTransport draft currently does not).
Fair enough. I suggest we replace that sentence with something along the lines of:

Discussion:
The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range. <del> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del> <ins> HTTP endpoints SHOULD use the Capsule-Protocol header field to simplify intermediary processing.  Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY alter this recommendation. </ins> 3.5.
Change:
End of section 3.3. (error handing) says: Not sure I can parse that sentence correctly. Is that ?
"terminates cleanly" is an abstract way of covering all HTTP versions notion of a stream FIN. This is not well defined (maybe lost in one of the restructuring edits?). If we think of HTTP/3 and the request stream being FIN'd at a particular offset, that is independent of a parser acting on the data in the stream. I think the way to make this clearer is to define or reference stream closures in respective HTTP docs.
How about this?
I don't understand the sentence structure here: When ..., if ..., then. Why is there a when and an if with a comma? May this should be: When ... and if ..., then? Sorry if that is grammatically correct but it really confuses me what the sentence is supposed to say... P.S.: clarifying the term "terminates cleanly" is also a good idea though.
We could rephrase as How does that sound?
Yes, that works for me. Thanks!
LGTM modulo nit

Discussion:
malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent. <del> When a stream carrying capsules terminates cleanly, if the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </del> <ins> If the receive side of a stream carrying capsules is terminated cleanly (for example, in HTTP/3 this is defined as receiving a QUIC STREAM frame with the FIN bit set) and the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </ins> 3.4.
Change:
The current text talks about "supporting" HTTP/3 datagrams. It seems we could tighten this up to be more about the willingness to receive datagrams a la URL
SGTM

Discussion:
2.1.1. <del> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </del> <ins> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </ins> The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or <del> 1.  A value of 0 indicates that HTTP Datagrams are not supported.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </del> <ins> 1.  A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </ins> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1.
Change:
In Abstract: "Both are intended for use by HTTP extensions, not applications." I think instead of using Both which is unclear, rather say HTTP Datagram and Capsule Protocol. That is at least what I interpret it to be in reference to.
Agree, we should just write this out explicitly.
SGTM

Discussion:
undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections. <del> Both are intended for use by HTTP extensions, not applications. </del> <ins> HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. </ins> 1.
Change:
... and indirectly associated with streams
Section 2: "HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams." I think the reference to "stream" is unclear here. Is the intention here to refer to "HTTP Message" or "HTTP Method" that would then in HTTP/2 and HTTP/3 map to a stream? Anyway align with next paragraph that uses "Method".
The subsequent use of "method" is not great. I would substitute both with "request" e.g. "HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them." ... "If an HTTP Datagram is received and it is associated with a request that does not support HTTP Datagrams, the receiver MUST terminate the request...."
Agreed, switching to request would be clearer

Discussion:
negotiated and conveyed using the Capsule Protocol; see datagram- capsule. <del> HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram associated with a method that has no known semantics for HTTP Datagrams is received, the receiver MUST abort the corresponding stream; if HTTP/3 is in use, the stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </del> <ins> HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram is received and it is associated with a request that has no known semantics for HTTP Datagrams, the receiver MUST terminate the request; if HTTP/3 is in use, the request stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </ins> 2.1.
Change:
Using a slight variation of David's proposed text on the issue.
In Section 2: "Negotiation is achieved using a setting; see Section 2.1.1." So first I though this was just lacking an "HTTP" prior to the setting. But, I think this glosses over the general negotiation complications across versions. In this section when the high level functionality is defined, I think actually the question of negotiation in general needs to be discussed, not only for HTTP/3.
I don't understand this issue, could you elaborate? I'm assuming you are talking about Section 2 para 2, which says: The remaining paragraphs deal with consideration of other versions, and mention negotiation.
I think we can improve clarity here. Right now we have in the "HTTP Datagrams" section. We should spell it out better, maybe:
WFM

Discussion:
When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including <del> unreliable delivery; see format.  Negotiation is achieved using a setting; see setting. </del> <ins> unreliable delivery; see format.  Negotiating the use of QUIC DATAGRAM frames for HTTP Datagrams is achieved via the exchange of HTTP/3 settings; see setting. </ins> When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP
Change:
Section 1: To my understanding WebSockets have no partial reliability features per that specification. So I think the formulation is missleading. To enable this in WebSockets, would it not require an update to WebSockets. I thought WebTrans is basically that update. So why not reference WebTrans here instead, it will anyway be an informational reference.
These are examples of potential future extensions that serve to illustrate the motivation. The fact that we're not planning on building such examples does not diminish their usefulness. Readers might be more familiar with WebSocket than with WebTransport at this point.

Discussion:
HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) <del> to enable desirable features like an unreliable version of the CONNECT method, and unreliable delivery in WebSockets RFC6455 (or its successors). </del> <ins> to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </ins> In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of
Change:
Section 1. "When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability." "This document also describes the HTTP Capsule Protocol in Section 3, to allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use." To me there is a bit of mismatch between these two sentences and what HTTP/3 is prior to this extension. The first indicate that datagram support is a capability of the underlying transport for the HTTP version but then link it hard to HTTP/3. While the HTTP/3 support is dependent on this extension in addition to a QUIC stack having Datagram support. While the second takes it as a property of the HTTP version, where it is assumed that earlier version can't support this, i.e. those that are defined to use TCP only. Technically a HTTP/3 endpoint with a QUIC stack without datagram support can use capsules and this document does not require an endpoint to support QUIC datagram. And the second statement should likely use a statement saying like … unavailable or undesirable, such as when TCP is used as transport protocol as with HTTP/1.x and HTTP/2.
Fair point, HTTP 1 and 2 don't strictly require TCP either. I think we can tweak these opening paragraphs a little to be more consistent and clear.
SGTM
Looks great modulo one tweak

Discussion:
data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT <del> method), and are compatible with all versions of HTTP.  When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability. </del> <ins> method), and are compatible with all versions of HTTP. When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is available to HTTP/3), HTTP Datagrams can use that capability. </ins> This document also describes the HTTP Capsule Protocol in capsule, to <del> allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use. </del> <ins> allow conveyance of HTTP Datagrams using reliable delivery.  This addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable, or where the transport protocol only provides reliable delivery, such as with HTTP/1 or HTTP/2 over TCP. </ins> 1.1.