jiebi/TextFlow huggingface dataset:
Original text:
indicates that the request has failed, and the client MUST therefore abort the request.  3.2. When using HTTP/1.1, a UDP proxying request will meet the following

Reviewer comments:
An application that tunnels UDP may rely on certain properties or features of the socket that the proxy creates. The draft covers some of these but doesn't seem to mention the UDP fragmentation. TURN has a whole section on this URL QUIC, for example, requires that and recommends the Don't Fragment (DF) bit MUST be set if possible. Since a proxy is agnostic to the application protocol in use (I'm assuming that because we don't mention the anywhere) perhaps CONNECT-UDP would benefit from a signal the client can send to the proxy to state it's DF preferences.
This sounds like a worthwhile extension draft? I don't think it's required to have a functional CONNECT-UDP protocol
One argument for doing it here is that one of the common uses of CONNECT-UDP will be to tunnel QUIC, and this is an obvious footgun in consideration of RFC 9000 requirements. The opposite way to solve the problem could be to add MUST/SHOULD language about proxies setting DF by default. And then require an extension to signal to disable it. But this is solutionizing a bit. Really, I want to be able to write a client that can have consistent expectations about the way datagram payload gets sent on UDP. Otherwise when things go wrong I'm left guessing and I might not have the information that the proxy did. I could even live with text in this document that raises this as a consideration but punts on the problem.
Note that this isn't just about setting in IPv4. It's also about whether to apply sender fragmentation, in IPv6. I would be OK with declaring that all fragmentation is off by default, and leave it to extensions to turn it on.
Good point Ben!
I'd be OK with saying proxies MUST NOT explicitly add fragmentation and SHOULD set the DF bit. We can't say MUST set DF because not all operating systems allow setting the DF bit on UDP sockets.
RFC 9000 says , not a fan?
"MUST ... if possible" is the same as "SHOULD" for me, I don't much care between them.

Revised text:
indicates that the request has failed, and the client MUST therefore abort the request. <ins> Proxies MUST NOT introduce fragmentation at the IP layer when forwarding HTTP Datagrams onto a UDP socket.  In IPv4, the Don't Fragment (DF) bit MUST be set if possible, to prevent fragmentation on the path.  Future extensions MAY remove these requirements. </ins> 3.2. When using HTTP/1.1, a UDP proxying request will meet the following
Original text:
2. Clients are configured to use UDP Proxying over HTTP via an URI <del> Template TEMPLATE.  The URI template MUST contain exactly two variables: "target_host" and "target_port".  Examples are shown below: </del>  Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query,

Reviewer comments:
. That template contains the and variables which convey the target host/port in the pseudo-header. This has the following benefits: allows custom schemes allows proxy to pick path they use However it has downsides: it requires parsing URI templates which is more of a pain than it seems it prevents reusing the same configuration between CONNECT-UDP and CONNECT-IP Alternatively, we could replace the configuration URI template with a configuration URL, and instead convey the target host/port in separate HTTP headers. This has the same benefits of the URI template without the downsides.
Discussed this issue at IETF 112, consensus in the room was to keep the URI template but to tighten the template restrictions.

Revised text:
2. Clients are configured to use UDP Proxying over HTTP via an URI  <ins> Template TEMPLATE with the variables "target_host" and "target_port". Examples are shown below: The URI template MUST be a level 3 template or lower.  The URI template MUST be in absolute form, and MUST include non-empty scheme, authority and path components.  The path component of the URI template MUST start with a slash "/".  All template variables MUST be within the path component of the URI.  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.  The URI template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.  If 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 proxy. </ins> Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query,
Original text:
When using HTTP/1.1, a UDP proxying request will meet the following requirements: <del> the method SHALL be "CONNECT". </del>  the request-target SHALL use absolute-form (see H1).

Reviewer comments:
For HTTP/1.1, should the method be "GET" or "CONNECT"? WebSockets uses GET -- are there any uses of "Extended CONNECT" that use CONNECT rather than GET? (issue based on by NAME
In my experience, H1.1 CONNECT for anything but it's intended purpose of proxying will see some deployment problems. The last HTTP spec admits some origins might respect it, but I suspect many HTTP components won't like it. I think sticking with GET plus Upgrade header field is a good choice
At IETF 113, after lengthy discussion the consensus is the room appeared to be to switch to GET so I'm merging so we have a version of the draft ready for WGLC

Revised text:
When using HTTP/1.1, a UDP proxying request will meet the following requirements:  <ins> the method SHALL be "GET". </ins> the request-target SHALL use absolute-form (see H1).
Original text:
6.  Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their

Reviewer comments:
Most likely just need a sentence saying that the data stream is treated the same regardless if capsules are used or not.
Adding that sentence sounds fine by me.

Revised text:
6. <ins> Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, Section 11 of PRIORITY. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their
Original text:
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>  <del> -1 / 4.  Receipt of a frame that includes a larger value MUST be </del>  treated as a connection error of type FRAME_ENCODING_ERROR. A variable-length integer indicating the context ID of the

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

Revised text:
streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2  <ins> -1, so the largest legal value of Quarter Stream ID is (2 </ins>  <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
Original text:
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>  Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule.

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

Revised text:
Capsules MUST be forwarded unmodified by intermediaries, with the exception of the DATAGRAM capsule; see datagram-capsule.  An  <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.
Original text:
the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1.  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>  8.

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

Revised text:
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.  <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.
Original text:
This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  8.2. This document will request IANA to register the following entry in

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

Revised text:
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
Original text:
large without suffering any loss; this can misrepresent the true path properties, defeating methods such as DPLPMTUD.  5. Implementations of HTTP/3 that support HTTP Datagrams can indicate

Reviewer comments:
In we discussed the risk presented by buffering extremely large datagram capsules. We should add some text to warn about this.
lgtm modulo nit

Revised text:
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
Original text:
that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream.  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

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

Revised text:
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
Original text:
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>  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.  4.4. This document defines the DATAGRAM capsule type (see iana-types for

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

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

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

Revised text:
The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range.  <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.
Original text:
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>  3.4.

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

Revised text:
malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent.  <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.
Original text:
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>  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>  QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1.

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

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

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

Revised text:
undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections.  <ins> HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. </ins> 1.