jiebi/CodeConvo huggingface dataset:
Change:
In layspeak I think this is saying "if a server sent the value 1 before, it MUST send 1 now. If a server sent 0 before, it MUST send 0 or 1 now". Could we maybe editorialize this to make it less likely for someone to do and end up sending ?
There is text in the doc stating that only 0 and 1 are valid. But I do agree that the current text is somewhat clunky. Can you send a PR?
Sure, I'll make a PR.

Discussion:
H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater <del> or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR. </del> <ins> than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. </ins> 6.
Change:
Seeing support and hearing no pushback, merging this as today marks the end of WGLC
When the first IANA registry was added to this document, it used "First Come First Served" to save time. This got carried over through the various changes and now the new "Capsule Type" registry is still marked that way. But in that corresponding time, the QUIC WG came up with a very good IANA policy for varint registries and documented it in RFC 9000. We should adopt that policy for Capsule Types.
I would like to note that changes like this is not editorial, it is something that should have consensus call.
Hi Magnus, I agree that this issue is not editorial. That's why I brought it up on this list over a week ago in its own thread (). This received two approvals on and no other comments or concerns. Hi MASQUE enthusiasts, While going over draft-ietf-masque-h3-datagram with Lucas to address some WGLC comments, we realized that the document introduced a new IANA 62bit registry for Capsule Types, with a "First Come First Served" registration policy. That was an oversight that was added a long time ago, and we'd like to switch it to using the same policy as the QUIC and HTTP/3 registries. If anyone objects to this change, please let us know on the GitHub issue: URL Thanks, David

Discussion:
5.4. This document establishes a registry for HTTP capsule type codes. <del> The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type. This registry initially contains the following entry: </del> <ins> The "HTTP Capsule Types" registry governs a 62-bit space, and operates under the QUIC registration policy documented in QUIC.  This new registry includes the common set of fields listed in QUIC.  In addition to those common fields, all registrations in this registry MUST include a "Capsule Type" field which contains a short name or label for the capsule type. Permanent registrations in this registry are assigned using the Specification Required policy (IANA-POLICY), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections IANA- POLICY and IANA-POLICY of IANA-POLICY. </ins> Capsule types with a value of the form 41 * N + 23 for integer values of N are reserved to exercise the requirement that unknown capsule types be ignored.  These capsules have no semantics and can carry arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. <ins> This registry initially contains the following entry: </ins>
Change:
Nit from AD review: The original sentence is ambiguously worded, and could be interpreted as saying that there could not be normal HTTP requests prior to the capsule protocol.
Thanks, this is an important clarification that makes clearer the original intent of the statement.

Discussion:
In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header <del> section, or the response header section.  As a result, only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections. </del> <ins> section, or the response header section.  As a result, only the last HTTP request on an HTTP/1.x connection can start the capsule protocol. </ins> In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding
Change:
Inspired by Martin Duke's suggestion to reference integer encoding more directly, this change just sticks it all in one place and makes it clear that there is no expectation to minimally-encode varints. Styled on similar references to QUIC made in URL

Discussion:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses terminology from QUIC. Where this document defines protocol types, the definition format uses the notation from QUIC.  Where fields within types are integers, they are encoded using the variable-length integer encoding from QUIC.  Integer values do not need to be encoded on the minimum number of bytes necessary. </ins> 2. HTTP Datagrams are a convention for conveying bidirectional and

2.1. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM <del> frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> frames uses the following format: </ins> 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

Definitions of new HTTP Upgrade Tokens can state that their associated request's data stream uses the Capsule Protocol.  If they do so, that means that the contents of the associated request's data <del> stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> stream uses the following format: </ins> An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by
Change:
Issue created in reponse to considerations section seems straightforward. extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC? The term HTTP extensions is defined in . Since we already have a normative reference to that document, I propose to resolve this issue by adding a reference to that section in our introduction.
Lgtm Reviewer: David Mandelberg Review result: Ready I did not notice any security issues with this document, and the security considerations section seems straightforward. (nit / question / feel free to ignore) I was a bit confused by the term "HTTP extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC?

Discussion:
1. <del> HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </del> <ins> HTTP extensions (as defined in HTTP) sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) 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 optionally multiplexed exchange
Change:
This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM

Discussion:
Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. <ins> Data streams are subject to the flow control mechanisms of the underlying layers (for example, HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control). </ins> 3.2. Definitions of new HTTP Upgrade Tokens can state that their

that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. <ins> When processing capsules, a receiver might tempted to accumulate the full length of the capsule value in the data stream before handling it.  This approach can consume flow control in underlying layers, which might lead to deadlocks if the capsule data exhausts the flow control window. </ins> 3.3. When an error occurs in processing the Capsule Protocol, the receiver

large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <ins> Since QUIC DATAGRAM frames are required to fit within a QUIC packet, implementations that reencode DATAGRAM capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire capsule before reencoding it.  This can cause flow control problems; see capsule- protocol. </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
Change:
There's some good guidance about parsing the Flow ID out of the HTTP/3 Datagram with respect to datagram payload length. But I'm not sure if the recommend error code of PROTOCOLVIOLATION is the most appropriate. This implies that the error is a Transport Error but I'd argue that at this point (parsing of the frame payload) that its an HTTP/3 Application error. Since we're not actually parsing a true HTTP/3 frame, just a view over a transport frame, H3FRAMEERROR seems too specific. So I think H3GENERALPROTOCOLERROR is the most straightforward. I wonder what others think.
I honestly am fine with any error for this, though I'd prefer to reuse an existing one to reduce complexity.

Discussion:
individual applications.  Note that this field can be empty. Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too <del> short to parse the flow identifier as a connection error of type PROTOCOL_VIOLATION. </del> <ins> short to parse the flow identifier as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 5.
Change:
To what does "these goals" refer? Original: When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including unreliable delivery; see
yeah, this text seems weird. Perhaps
Or how about simply
I made typos in my suggestion that doesn't help, sorry. IIRC the original text is a roundabout way of saying - we use a special payload in QUIC datagrams in order to achieve unreliable datagram multiplexing. This makes more sense in the context of the next that then states HTTP/2 frames provide demultiplexing.
Right, how about

Discussion:
an HTTP request. When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC <del> DATAGRAM frame can be used to achieve these goals, including 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. </del> <ins> DATAGRAM frame can be used to provide demultiplexing and 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:
We suggest rephrasing this sentence. The phrase "might have practical barriers to determining..." is difficult to parse. Does the suggested text below accurately convey the intended meaning? Original: 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. Perhaps: Generating an error is not mandatory in this case because HTTP/3 implementations might present practical barriers when determining the active stream concurrency limit that is applied by the QUIC layer.
The point we're making here is that the implementations might encounter barriers, either because they contain them, or the API the are using presents them. The suggestion doesn't cover these two response. Alternative Perhaps: Generating an error is not mandatory in this case because there might be practical barriers that prevent HTTP/3 implementations from determining the active stream concurrency at the QUIC layer.
How about we just nuke this sentence?
I've just rememberd this text is verbatim copied from URL ADs seem to like justifcations for SHOULD requirements. If we're worried about verbosity, then how about Generating an error is not mandatory because the QUIC stream limit may be unknown to the HTTP/3 layer.
That works for me

Discussion:
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 an HTTP/3 connection error of <del> 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. </del> <ins> type H3_ID_ERROR.  Generating an error is not mandatory because the QUIC stream limit might be unknown to the HTTP/3 layer. </ins> Prioritization of HTTP/3 Datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams and MAY
Change:
In the following text, should the names of the status codes appear as they do in the rest of the document? Original: ...a status code that is both different from 101 and outside the 2xx range. Perhaps: ...a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range.
solid improvement, let's do it
That sounds good to me

Discussion:
possible for HTTP Upgrade or Extended CONNECT. The Capsule-Protocol header field MUST NOT be used on HTTP responses <del> with a status code that is both different from 101 and outside the 2xx range. </del> <ins> with a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range. </ins> When using the Capsule Protocol, HTTP endpoints SHOULD send the Capsule-Protocol header field to simplify intermediary processing.
Change:
Is it really the Definition that performs the security analysis? Original: Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol need to perform a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol. Perhaps: Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol need to include a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol.
I prefer the RFC editor suggestion here.
Same, works for me

Discussion:
commonly accessed via JavaScript in web browsers). Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol <del> need to perform a security analysis that considers the impact of HTTP </del> <ins> need to include a security analysis that considers the impact of HTTP </ins> Datagrams and Capsules in the context of their protocol. 5.
Change:
We had the following questions related to the descriptions of "HTTP Datagrams" in a few places throughout the text. a) We see the following similar sentences in the Abstract, Introduction, and , respectively. Please review and let us know if this text should be made more uniform. Original (Abstract): This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. Original (Intro): In , this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange of data inside an HTTP connection. Original (): HTTP Datagrams are a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible. b) Pending changes made in (a) above, we will update the first sentence of the Abstract as follows unless we hear objection Original: This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. Perhaps: This document describes a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection called “HTTP Datagrams”. c) This sentence, which is somewhat related, seems a bit odd in that it seems sending something "unreliably" is desired. Should any clarification here be added? Original: In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension.
a) I'm happy with the abstract being succinct. I think we could probably my the Intro and Section 2 more uniform. Suggest use Section 2 text in the intro. b) I'm not a huge fan of the scary quotes suggested here. I like what we have already TBH. c) This seems fine. No change needed IMO
Fully agree with your comments

Discussion:
unreliable delivery (such as when the QUIC DATAGRAM extension DGRAM is available to HTTP/3 H3), HTTP Datagrams can use that capability. <del> In capsule, this document describes the HTTP Capsule Protocol, which allows the 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.1 H1 or HTTP/2 H2 over TCP TCP. </del> <ins> In capsule, this document describes HTTP Datagrams, a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible.  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.1 H1 or HTTP/2 H2 over TCP TCP. </ins> 1.1.
Change:
The comparison to UDP sockets is not as good as a comparison to streams. UDP sockets are sometimes spun up in the fashion described, but they are also often a fixed thing, such as the socket that a DNS server listens on. That evokes the wrong model in which the caller chooses and there is some possibility of persistence.

Discussion:
2.1. Flow identifiers represent bidirectional flows of datagrams within a <del> single QUIC connection.  These are conceptually similar to UDP ports and allow basic demultiplexing of application data.  The primary role of flow identifiers is to provide a standard mechanism for demultiplexing application data flows, which may be destined for different processing threads in the application, akin to UDP sockets. </del> <ins> single QUIC connection.  These are conceptually similar to streams in the sense that they allow multiplexing of application data.  Of course flows lack any of the ordering or reliability guarantees of streams. </ins> Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another.  If