jiebi/TextFlow huggingface dataset:
Original text:
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>  2.1.

Reviewer comments:
... 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

Revised text:
negotiated and conveyed using the Capsule Protocol; see datagram- capsule.  <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.
Original text:
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>  When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP

Reviewer comments:
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

Revised text:
When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including  <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
Original text:
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>  In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of

Reviewer comments:
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.

Revised text:
HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM)  <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
Original text:
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>  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>  1.1.

Reviewer comments:
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

Revised text:
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  <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  <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.
Original text:
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>  6.

Reviewer comments:
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.

Revised text:
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  <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.
Original text:
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>  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. 

Reviewer comments:
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

Revised text:
5.4. This document establishes a registry for HTTP capsule type codes.  <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>
Original text:
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>  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

Reviewer comments:
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.

Revised text:
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  <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
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  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>  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>  An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by

Reviewer comments:
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

Revised text:
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  <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  <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
Original text:
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>  In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange

Reviewer comments:
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?

Revised text:
1.  <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
Original text:
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>  5.

Reviewer comments:
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.

Revised text:
individual applications.  Note that this field can be empty. Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too  <ins> short to parse the flow identifier as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 5.
Original text:
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>  When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP

Reviewer comments:
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

Revised text:
an HTTP request. When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC  <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
Original text:
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>  Prioritization of HTTP/3 Datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams and MAY

Reviewer comments:
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

Revised text:
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  <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