jiebi/TextFlow huggingface dataset:
Original text:
7. <del> Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </del>  To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection <del> when rejecting an HTTP CONNECT request, without processing any </del>  further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response.

Reviewer comments:
The current text could be interpreted as applying to other HTTP versions, which is not the intent. cc NAME

Revised text:
7.  <ins> In HTTP/1.1, clients that send CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </ins> To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection  <ins> when rejecting an HTTP/1.1 CONNECT request, without processing any </ins> further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response.
Original text:
the name string is empty, and the value string is the value of name-value-pair. <del> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del>  Remove any leading or trailing WSP characters from the name string and the value string.

Reviewer comments:
Adds an example to the Examples section to clarify and illustrate that cookie names are case-sensitive. Additionally adds a clarification that cookie names could be empty to improve readability.
Agreed
What should a user agent do with the "set-cookie-string" ? The current RFC says that the name string can be empty and then in a subsequent step to ignore that cookie. URL
Hi, instructs >If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. which covers the case of a nameless cookie such as . I think clarifying, similar to the value string, that the name string could be possibly empty would improve readability, I'll make that change.
Thank you NAME This means there is a change in the recommended parsing algorithm: now empty named cookies are ok. Is that intended?
That's correct. Even though it's strongly not recommended we found that servers still produced unusual set-cookie strings, including empty cookie names, and many UAs accepted them. So the parsing change is meant to standardized behavior so that UAs can at least all do the same thing with them. I still strongly recommend that any sites only use cookies with a non-empty name that conforms to 's syntax. Same for the value field too, now that I'm mentioning it. It'll probably work otherwise, but why make your life harder?
I think the spec would benefit from getting this fact explicitly specified. and are two different cookies.
If you had asked me if this already existed I would have guessed yes. Seems like an obvious improvement
LGTM. It'd be very nice if we could remove the notion of empty cookie names, but since we can't we should document them clearly. :/

Revised text:
the name string is empty, and the value string is the value of name-value-pair.  <ins> Otherwise, the (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string.
Original text:
yet complete indicated by the "Upload-Complete" field value set to false, the server MUST acknowledge it by responding with a "201 (Created)" status code and the "Upload-Complete" field value set to <del> true. </del>  If the request includes the "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to

Reviewer comments:
If the client gives Upload-Complete=false then the server must respond with Upload-Complete=false and not Upload-Complete=true.
Thank you for this correction!

Revised text:
yet complete indicated by the "Upload-Complete" field value set to false, the server MUST acknowledge it by responding with a "201 (Created)" status code and the "Upload-Complete" field value set to  <ins> false. </ins> If the request includes the "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to
Original text:
1.1.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP

Reviewer comments:
It's customary to put the terminology and BCP 14 block in the same section, but this works.

Revised text:
1.1. <ins> This document uses terminology defined in HTTP. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP
Original text:
Abstract This document describes how "http" URIs can be accessed using <del> Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. </del>  Note to Readers

Reviewer comments:
NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.

Revised text:
Abstract This document describes how "http" URIs can be accessed using  <ins> Transport Layer Security (TLS) in HTTP/2 to mitigate pervasive monitoring attacks. </ins> Note to Readers
Original text:
This document describes a use of HTTP Alternative Services RFC7838 to decouple the URI scheme from the use and configuration of underlying <del> encryption, allowing a "http" URI RFC7230 to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </del>  <del> Serving "https" URIs requires avoiding Mixed Content W3C.CR-mixed- content-20160802, which is problematic in many deployments.  This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding these issues, while still providing </del>  protection against passive attacks. <del> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks, and does not change the security context of the connection. </del>  Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").

Reviewer comments:
NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.

Revised text:
This document describes a use of HTTP Alternative Services RFC7838 to decouple the URI scheme from the use and configuration of underlying  <ins> encryption.  It allows HTTP/2 RFC7540 to access a "http" URI RFC7230 using Transport Layer Security (TLS) RFC5246 with Opportunistic Security RFC7435. </ins>  <ins> This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (describe in W3C.CR-mixed-content-20160802) while still providing </ins> protection against passive attacks.  <ins> Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs; Opportunistic Security is vulnerable to active attacks, and does not change the security context of the connection. </ins> Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").
Original text:
2.1. <del> Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences.  The user can be given the choice to enable, disable, or override specific hints. </del>  The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for

Reviewer comments:
Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM

Revised text:
2.1.  <ins> Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations.  Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions.  Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. </ins> The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for
Original text:
6. The "Downlink" request header field is a number that indicates the <del> client's maximum downlink speed in megabits per second (Mbps), as defined by the "downlinkMax" attribute in the W3C Network Information API (NETINFO). </del>  If Downlink occurs in a message more than once, the minimum value should be used to override other occurrences.

Reviewer comments:
Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM

Revised text:
6. The "Downlink" request header field is a number that indicates the  <ins> client's maximum downlink speed in megabits per second (Mbps). </ins> If Downlink occurs in a message more than once, the minimum value should be used to override other occurrences.
Original text:
2. <del> Clients include the Tunnel-Protocol Request Header field in a HTTP Connect request to indicate the application layer protocol or protocols that will be used within the tunnel. </del>  2.1.

Reviewer comments:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Revised text:
2.  <ins> Clients include the `Tunnel-Protocol` Request Header field in an HTTP CONNECT request to indicate the application layer protocol will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.
Original text:
2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del>  ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) must

Reviewer comments:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Revised text:
2.2.  <ins> The ABNF (Augmented Backus-Naur Form) syntax for the `Tunnel- Protocol` header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) must
Original text:
4. In case of using HTTP CONNECT to a TURN server the security <del> consideration of RFC7231 apply.  It states that there "are </del>  significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol request header field described in this document is an optional header and HTTP Proxies may of course not support the header and therefore ignore it.  If the header is not present or ignored then the proxy has no explicit indication as to the purpose of the tunnel on which to provide consent, this is the generic case that exists without the Tunnel-Protocol header. </del> 

Reviewer comments:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Revised text:
4. In case of using HTTP CONNECT to a TURN server the security  <ins> considerations of RFC7231 apply.  It states that there "are </ins> significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."  <ins> The `Tunnel-Protocol` request header field described in this document is an optional header.  Clients and HTTP Proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is indistinguishable from the case where either client or proxy does not support the `Tunnel-Protocol` header. </ins>
Original text:
2.2. When presented with a request that contains one or more client hint <del> headers, servers can optimise the response based upon the information </del>  in them.  When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-key), to indicate

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
2.2. When presented with a request that contains one or more client hint  <ins> headers, servers can optimize the response based upon the information </ins> in them.  When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-key), to indicate
Original text:
Implementers ought to provide mechanisms and policies to control how and when such hints are advertised.  For example, they could require <del> origin opt-in; restrict delivery to same origin subrequests; limit delivery to requests that already carry indentifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </del>  6.

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Implementers ought to provide mechanisms and policies to control how and when such hints are advertised.  For example, they could require  <ins> origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </ins> 6.
Original text:
6.2.  Header field name: Content-DPR Applicable protocol: HTTP Status: standard

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
6.2. <ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints 6.3. </ins> Header field name: Content-DPR Applicable protocol: HTTP Status: standard
Original text:
Specification document(s): content-dpr of this document Related information: for Client Hints <del> 6.3. </del>  Header field name: Downlink Applicable protocol: HTTP

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Specification document(s): content-dpr of this document Related information: for Client Hints  <ins> 6.4. </ins> Header field name: Downlink Applicable protocol: HTTP
Original text:
Specification document(s): downlink of this document Related information: for Client Hints <del> 6.4. </del>  Header field name: DPR Applicable protocol: HTTP

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Specification document(s): downlink of this document Related information: for Client Hints  <ins> 6.5. </ins> Header field name: DPR Applicable protocol: HTTP
Original text:
Specification document(s): dpr of this document Related information: for Client Hints <del> 6.5. </del>  Header field name: Save-Data Applicable protocol: HTTP

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Specification document(s): dpr of this document Related information: for Client Hints  <ins> 6.6. </ins> Header field name: Save-Data Applicable protocol: HTTP
Original text:
Specification document(s): save-data of this document Related information: for Client Hints <del> 6.6. </del>  Header field name: Viewport-Width Applicable protocol: HTTP

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Specification document(s): save-data of this document Related information: for Client Hints  <ins> 6.7. </ins> Header field name: Viewport-Width Applicable protocol: HTTP
Original text:
Specification document(s): viewport-width of this document Related information: for Client Hints <del> 6.7. </del>  Header field name: Width Applicable protocol: HTTP

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
Specification document(s): viewport-width of this document Related information: for Client Hints  <ins> 6.8. </ins> Header field name: Width Applicable protocol: HTTP
Original text:
2.1. <del> The ORIGIN frame type is 0xb (decimal 11). </del>  The ORIGIN frame's payload contains the following fields, sets of which may be repeated within the frame to indicate multiple origins:

Reviewer comments:
While testing firefox's implementation of this draft Vlad determined that some versions of Chrome throw PROTOCOL_ERROR and close the connection if it receives a type 0xB frame with a non zero length on stream 0. Other frame type numbers, such as 0xC do not seem to have that problem. testing indicates this is fixed in version 59 and is a problem previous to that. (57 is in release as I write this). presumably this is related to historical code around BLOCKED which was proposed to use 0xB. Prudence says to just use a different code point for the moment.
Question for NAME and NAME should we somehow reserve 0xb to avoid this problem?
If this is fixed in Chrome 59, why bother? Actually, I'd also revert this change.
Neither. There are still old Chrome versions deployed (some people lag, for various reasons), so it's not safe to use now, but it should be in the not-to-distant future; we just need to wait a while to use it (presumably for another extension). Reserving it for all time would be a bad precedent.

Revised text:
2.1.  <ins> The ORIGIN frame type is 0xc (decimal 12). </ins> The ORIGIN frame's payload contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: