jiebi/TextFlow huggingface dataset:
Original text:
Remove any leading or trailing WSP characters from the attribute- name string and the attribute-value string. <del> If the attribute-value is longer than 1024 bytes, ignore the </del>  cookie-av string and return to Step 1 of this algorithm. Process the attribute-name and attribute-value according to the

Reviewer comments:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Revised text:
Remove any leading or trailing WSP characters from the attribute- name string and the attribute-value string.  <ins> If the attribute-value is longer than 1024 octets, ignore the </ins> cookie-av string and return to Step 1 of this algorithm. Process the attribute-name and attribute-value according to the
Original text:
If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely.  Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.

Reviewer comments:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Revised text:
If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely. <ins> If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie entirely. </ins> Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.
Original text:
attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last <del> attribute in the cookie-attribute-list with an attribute-name of "Domain". </del>  Otherwise:

Reviewer comments:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Revised text:
attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last  <ins> attribute in the cookie-attribute-list with both an attribute- name of "Domain" and an attribute-value whose length is no more than 1024 octets. </ins> Otherwise:
Original text:
If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value <del> of the last attribute in the cookie-attribute-list with an attribute-name of "Path".  Otherwise, set the cookie's path to the </del>  default-path of the request-uri. If the cookie-attribute-list contains an attribute with an

Reviewer comments:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Revised text:
If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value  <ins> of the last attribute in the cookie-attribute-list with both an attribute-name of "Path" and an attribute-value whose length is no more than 1024 octets.  Otherwise, set the cookie's path to the </ins> default-path of the request-uri. If the cookie-attribute-list contains an attribute with an
Original text:
server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data <del> carriage mechanisms, they MAY also define how this priority scheme </del>  can be applied. 4.

Reviewer comments:
Thank you for the fix.
FWIW, I would prefer s/MAY/can/ - there is no normative effect of a choice. Originally posted by NAME in URL

Revised text:
server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data  <ins> carriage mechanisms, they can also define how this priority scheme </ins> can be applied. 4.
Original text:
NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm <del> handles them explicitly. </del>  A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string: <del> If the set-cookie-string contains a %x00-1F / %x7F (CTL) character: Abort these steps and ignore the set-cookie-string entirely. </del>  If the set-cookie-string contains a %x3B (";") character:

Reviewer comments:
This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks

Revised text:
NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm  <ins> handles them explicitly.  Horizontal tab (%x09) is excluded from the CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string:  <ins> If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F character (CTL characters excluding HTAB): Abort these steps and ignore the set-cookie-string entirely. </ins> If the set-cookie-string contains a %x3B (";") character:
Original text:
If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely. <del> If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely. </del>  If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie

Reviewer comments:
This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks

Revised text:
If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely.  <ins> If the cookie-name or the cookie-value contains a %x00-08 / %x0A- 1F / %x7F character (CTL characters excluding HTAB), abort these steps and ignore the cookie entirely. </ins> If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie
Original text:
client's original signature values. The following is a non-normative example of header fields a reverse <del> proxy sets in addition to the examples in the previous sections.  The original signature is included under the identifier "sig1", and the reverse proxy's signature is included under "proxy_sig".  The proxy uses the key "rsa-test-key" to create its signature using the "rsa- v1_5-sha256" signature value.  This results in a signature input string of: </del>  And a signature output value of: These values are added to the HTTP request message by the proxy.  The <del> different signature values are wrapped onto separate lines to increase human-readability of the result. </del>  The proxy's signature and the client's original signature can be <del> verified independently for the same message, depending on the needs of the application. </del>  5.

Reviewer comments:
Minor editorial cleanups, including: added client cert example updated multiple signature example prepare for next revision

Revised text:
client's original signature values. The following is a non-normative example of header fields a reverse  <ins> proxy sets in addition to the examples in the previous sections. The client's request includes a signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header defined in RFC7239.  Note that since the client's signature already covers the client's "Signature-Input" value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  This results in a signature input string of: </ins> And a signature output value of: These values are added to the HTTP request message by the proxy.  The  <ins> original signature is included under the identifier "sig1", and the reverse proxy's signature is included under the label "proxy_sig". The proxy uses the key "test-key-rsa" to create its signature using the "rsa-v1_5-sha256" signature algorithm, while the client's original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. </ins> The proxy's signature and the client's original signature can be  <ins> verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </ins> 5.
Original text:
with the types defined in params and error-types respectively; see register-param and register-error for its associated procedures.  4. One of the primary security concerns when using Proxy-Status is

Reviewer comments:
wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See

Revised text:
with the types defined in params and error-types respectively; see register-param and register-error for its associated procedures. <ins> Additionally, please register the following entry in the Hypertext Transfer Protocol (HTTP) Field Name Registry: Field name: Proxy-Status Status: permanent Specification document(s): [this document] Comments: </ins> 4. One of the primary security concerns when using Proxy-Status is
Original text:
2.3.  A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/

Reviewer comments:
wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See

Revised text:
2.3. <ins> HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of I-D.ietf-httpbis-cache.  When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered.  In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, negatively impacting cache efficiency. For example, a response stored by a CDN cache might be served with the following headers: From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from other caches' standpoint, this response is already stale.  See AGE-PENALTY for more discussion. When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects.  Some techniques seen in deployments include: Removing the Age header field Updating the Date header field value to the current time Updating the Expires header field value to the current time, plus any Cache-Control: max-age value This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so. 2.4. </ins> A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/
Original text:
This document describes a use of HTTP Alternative Services I-D.ietf- httpbis-alt-svc to decouple the URI scheme from the use and configuration of underlying encryption, allowing a "http" URI RFC7230 <del> to be accessed using TLS RFC5246 opportunistically. </del>  Serving "https" URIs require acquiring and configuring a valid certificate, which means that some deployments find supporting TLS

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
This document describes a use of HTTP Alternative Services I-D.ietf- httpbis-alt-svc to decouple the URI scheme from the use and configuration of underlying encryption, allowing a "http" URI RFC7230  <ins> to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </ins> Serving "https" URIs require acquiring and configuring a valid certificate, which means that some deployments find supporting TLS
Original text:
Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon"). <del> By its nature, this technique is vulnerable to active attacks.  A mechanism for partially mitigating them is described in commit. </del>  1.1.

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").  <ins> A mechanism for partially mitigating active attacks is described in commit. </ins> 1.1.
Original text:
As defined in that specification, one way of establishing this is using a TLS-based protocol with the certificate checks defined in <del> RFC2818.  Clients MAY impose additional criteria for establishing reasonable assurances. </del>  For the purposes of this specification, an additional way of establishing reasonable assurances is available when the alternative

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
As defined in that specification, one way of establishing this is using a TLS-based protocol with the certificate checks defined in  <ins> RFC2818.  Clients are permitted to impose additional criteria for establishing reasonable assurances. </ins> For the purposes of this specification, an additional way of establishing reasonable assurances is available when the alternative
Original text:
the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication. <del> When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </del>  The origin and alternative service's hostnames are the same when compared in a case-insensitive fashion, and

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication.  <ins> A client acquires an http-opportunistic response by making a GET request to the "http-opportunistic" well-known URI.  When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </ins> The origin and alternative service's hostnames are the same when compared in a case-insensitive fashion, and
Original text:
is initially created for "http" URIs without authenticating the server cannot be used for "https" URIs until the server certificate is successfully authenticated.  Section 3.1 of RFC2818 describes the <del> basic mechanism, though the authentication considerations in I- D.ietf-httpbis-alt-svc also apply. </del>  Connections that are established without any means of server <del> authentication (for instance, the purely anonymous TLS cipher suites), cannot be used for "https" URIs. </del>  5.

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
is initially created for "http" URIs without authenticating the server cannot be used for "https" URIs until the server certificate is successfully authenticated.  Section 3.1 of RFC2818 describes the  <ins> basic mechanism, though the authentication considerations in Section 2.1 of I-D.ietf-httpbis-alt-svc also apply. </ins> Connections that are established without any means of server  <ins> authentication (for instance, the purely anonymous TLS cipher suites) cannot be used for "https" URIs. </ins> 5.
Original text:
5.1. An origin can reduce the risk of attacks on opportunistically secured <del> connections by committing to provide an secured, authenticated </del>  alternative service.  This is done by including the optional "commit" member in the http-opportunistic well-known resource (see well- known).  This feature is optional due to the requirement for server

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
5.1. An origin can reduce the risk of attacks on opportunistically secured  <ins> connections by committing to provide a secured, authenticated </ins> alternative service.  This is done by including the optional "commit" member in the http-opportunistic well-known resource (see well- known).  This feature is optional due to the requirement for server
Original text:
The "origins" member of the root object has a value of an array of strings, one of which is a case-insensitive character-for- character match for the origin in question, serialised into <del> Unicode as per RFC6454, Section 6.1, and </del>  This specification defines one additional, optional member of the root object, "commit" in commit.  Unrecognised members MUST be

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
The "origins" member of the root object has a value of an array of strings, one of which is a case-insensitive character-for- character match for the origin in question, serialised into  <ins> Unicode as per Section 6.1 of RFC6454. </ins> This specification defines one additional, optional member of the root object, "commit" in commit.  Unrecognised members MUST be
Original text:
7. <del> This specification registers a Well-known URI RFC5785: </del>  URI Suffix: http-opportunistic Change Controller: IETF <del> Specification Document(s): [this specification] </del>  Related Information:

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
7.  <ins> This specification registers a Well-Known URI RFC5785: </ins> URI Suffix: http-opportunistic Change Controller: IETF  <ins> Specification Document(s): well-known of [this specification] </ins> Related Information:
Original text:
8.2. A downgrade attack against the negotiation for TLS is possible.  With <del> commitment commit, this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </del>  For example, because the "Alt-Svc" header field I-D.ietf-httpbis-alt- svc likely appears in an unauthenticated and unencrypted channel, it

Reviewer comments:
I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.

Revised text:
8.2. A downgrade attack against the negotiation for TLS is possible.  With  <ins> commitment (see commit), this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </ins> For example, because the "Alt-Svc" header field I-D.ietf-httpbis-alt- svc likely appears in an unauthenticated and unencrypted channel, it