jiebi/TextFlow huggingface dataset:
Original text:
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>  When using the Capsule Protocol, HTTP endpoints SHOULD send the Capsule-Protocol header field to simplify intermediary processing.

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

Revised text:
possible for HTTP Upgrade or Extended CONNECT. The Capsule-Protocol header field MUST NOT be used on HTTP responses  <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.
Original text:
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>  Datagrams and Capsules in the context of their protocol. 5.

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

Revised text:
commonly accessed via JavaScript in web browsers). Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol  <ins> need to include a security analysis that considers the impact of HTTP </ins> Datagrams and Capsules in the context of their protocol. 5.
Original text:
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>  1.1.

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

Revised text:
unreliable delivery (such as when the QUIC DATAGRAM extension DGRAM is available to HTTP/3 H3), HTTP Datagrams can use that capability.  <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.
Original text:
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>  Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another.  If

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

Revised text:
2.1. Flow identifiers represent bidirectional flows of datagrams within a  <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
Original text:
wishes to use four datagram flows for the lifetime of its request stream could look like this: <del> In this example, 42 is the unnamed flow, 44 represents the name "ecn- ect0", 46 represents "ecn-ect1", and 48 represents "ecn-ce".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </del>  Even if a sender attempts to communicate the meaning of a flow before it uses it in an HTTP/3 datagram, it is possible that its peer will

Reviewer comments:
Currently, the Datagram-Flow-Id Header Field Definition section contains examples of the Datagram-Flow-Id header, which includes a 4-flow mechanism for conveying ECN information: This example seems to be tripping people up, myself included, by attempting to solve a problem of in-band signaling of non-UDP-payload bits by providing these streams, and drawing attention to that problem rather than the capability being described. I propose we remove this example until we have a better one to replace it. If we cannot find a good example, that also lends some evidence that perhaps we don't need the feature of creating multiple Datagram-Flow-Id associations in the same request.

Revised text:
wishes to use four datagram flows for the lifetime of its request stream could look like this:  <ins> In this example, 42 is the unnamed flow, 44 represents the name "foo", 46 represents "bar", and 48 represents "baz".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </ins> Even if a sender attempts to communicate the meaning of a flow before it uses it in an HTTP/3 datagram, it is possible that its peer will
Original text:
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with <del> the same Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with an unknown Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule. </del>  Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using

Reviewer comments:
URL it clear what the spec is allowing, we should make a note in Section 4.4 that the ordering/buffering requirements of DATGRAM frames and register capsules (from sec 3) do not apply to intermediaries when forwarding. That's tangential to Luca's OP so we can spin it off separately. Originally posted by NAME in URL

Revised text:
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with  <ins> the same Context ID.  However, reordering can cause DATAGRAM frames to be received with an unknown Context ID.  Receipt of such frames MUST NOT be treated as an error.  Endpoints SHALL drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule.  Intermediaries SHALL drop the DATAGRAM frame silently, MAY buffer it, or forward it on immediately. </ins> Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using
Original text:
demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
err'ing on the side of succinct
There's now several different concepts to wrangle in this document. Reading from the top, we first tackle multiplexing (the major motivation for the document), then the frame, then capsules. Capsules underpin the mechanics of multiplexing. I don't think we can fix this chicken and egg problem but adding a brief overview of the concepts and terms before they are tackled in the prose could help readability.
I think that sounds like a great idea!
Thanks for doing this!

Revised text:
demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP. <ins> This document is structured as follows: multiplexing presents core concepts for multiplexing across HTTP versions. datagram-contexts defines datagram contexts, an optional end- to-end multiplexing concept scoped to each HTTP request. datagram-formats defines datagram formats, which are scoped to contexts.  Formats communicate the format and encoding of datagrams sent using the associated context. Contexts are identified using a variable-length integer. Requirements for allocating identifier values are detailed in context-id-alloc. format defines how QUIC DATAGRAM frames are used with HTTP/3. setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP requests, after which Capsules, an end-to-end message, can be sent. The following Capsule types are defined, together with guidance for defining new types: REGISTER_DATAGRAM_CONTEXT REGISTER_DATAGRAM_NO_CONTEXT CLOSE_DATAGRAM_CONTEXT DATAGRAM </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a <del> 62-bit integer (0 to 2^62-1). </del>  While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated <del> with, divided by four.  (The division by four stems from the fact </del>  that HTTP requests are sent on client-initiated bidirectional <del> streams, and those have stream IDs that are divisible by four.) </del>  A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is

Reviewer comments:
…king hte law Also, switch to format to beatuiful superscript HTML rendering as used by RFC 9000.
Stating the obvious here. But we're using value with a legal range larger than semantically legal. RFC 9000 has some similar caveats with MAX_STREAMS URL To address this, the suggestion is to add something like
That suggestion sounds good to me.

Revised text:
register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a  <ins> 62-bit integer (0 to 2 -1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated  <ins> with, divided by four (the division by four stems from the fact </ins> that HTTP requests are sent on client-initiated bidirectional  <ins> streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1 / 4.  Receipt of a frame that includes a larger value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is
Original text:
consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery. <del> Much of the focus of this document is on reliable media using HTTP over TCP, which is widely used because </del>  support for HTTP is widely available in a wide range of operating systems, HTTP can make use of already-deployed caching infrastructure.  Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For

Reviewer comments:
From NAME " reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?
NAME - Thanks for catching this. The relevant point here is that HTTP is carried over reliable transport protocols. The behavior of specific transport protocols is described in subsections of Section 6. I've clarified that in Section 2.

Revised text:
consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery.  <ins> Much of the focus of this document is on reliable media using HTTP. HTTP is widely used because </ins> support for HTTP is widely available in a wide range of operating systems, HTTP can make use of already-deployed caching infrastructure. <ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For
Original text:
internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption <del> in Bittorrent, similar to an arms race, and set off discussions about "Net Neutrality" and calls for regulatory action. </del>  Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to

Reviewer comments:
From NAME Unsure whether the end part of this section is relevant to the document as it is rather anecdotical.
We should explain the impact on the Internet, the IETF, and regulatory agencies from the BitTorrent experience.
Working session discussion: yes this is anecdotal, but is a worthwhile example to keep because it adds a concrete example to the abstract notion of unpredictable traffic and its impacts. We think the right response is to add a paragraph to this anecdote explaining the ultimate impact to the internet that this example of unpredictable traffic had as a conclusion to explain how the experiences from unpredictable traffic can cause large and sudden shifts in network operational practice.
NAME - I agree. I suspect that the number of people who remember the impact of Comcast attending to "manage" BitTorrent on residential networks is declining every year, but it was horrendous at the time. We should make it clear that you don't have to have a hurricane to end up with sudden and massive spikes in network traffic that you never planned for.
I teach this every year to keep the new generation aware of some of the non-sense stuff their elder brothers (or sisters) had to put up with. It was not just Comcast, I can name 5 other names based on my own testing at that time.
I like the last paragraph of the PR ;-) Thanks
LGTM

Revised text:
internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption  <ins> in Bittorrent, and complaints to regulators calling for regulatory action. The BitTorrent case study is just one example, but the example is included here to make it clear that unpredicted and unpredictable massive traffic spikes may not be the result of natural disasters, but they can still have significant impacts. </ins> Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to
Original text:
forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption"). <del> Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </del>  Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be This document does not take a position on whether those goals are "valid" (whatever that might mean). <del> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications. </del> Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.

Reviewer comments:
From NAME Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).
This paragraph appears later in the document - I can move this up under the bullet points and make that clearer.
Fixed as in my previous comment.
BTW, unsure how the authors want me to mark "I have read the change and I like it" ? Currently, simply using a "thum up" emoticon on the solution comment. Let me know if you prefer another marking.
NAME If I can't hear you either giggling or screaming all the way to Texas, and I see a "thumbs up" emoticon, that's clear enough to me!
LGTM

Revised text:
forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption").  <ins> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications.  Of course, both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </ins> Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be This document does not take a position on whether those goals are "valid" (whatever that might mean).  Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.
Original text:
dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. <del> More broadly, I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It discusses what network operators can consider in some detail. </del> 7. "Encrypted Media" has at least three meanings: these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.  7.2. Although the IETF has put considerable emphasis on end-to-end

Reviewer comments:
From NAME Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).
Agree, will reference (was draft-ietf-tsvwg-transport-encrypt) Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols

Revised text:
dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic.  7. "Encrypted Media" has at least three meanings: these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. <ins> I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol that is used to encapsulate HTTP/3, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  It discusses what network operators can consider in some detail. More broadly, RFC 9065 RFC9065, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end