jiebi/TextFlow huggingface dataset:
Original text:
protocol.version.  For brevity, the protocol-name is omitted when the received protocol is HTTP. <del> The received-by portion of the field value is normally the host and optional port number of a recipient server or client that subsequently forwarded the message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol. </del>  <del> A sender MAY generate comments in the Via header field to identify the software of each recipient, analogous to the </del>  and <del> header fields.  However, all comments in the Via field are optional, and a recipient MAY remove them prior to forwarding the message. </del>  For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
protocol.version.  For brevity, the protocol-name is omitted when the received protocol is HTTP.  <ins> The received-by portion is normally the host and optional port number of a recipient server or client that subsequently forwarded the message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol. </ins>  <ins> A sender MAY generate comments to identify the software of each recipient, analogous to the </ins> and  <ins> header fields.  However, comments in Via are optional, and a recipient MAY remove them prior to forwarding the message. </ins> For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
Original text:
the firewall by an appropriate pseudonym for that host. An intermediary MAY combine an ordered subsequence of Via header <del> field entries into a single such entry if the entries have identical </del>  received-protocol values.  For example, could be collapsed to <del> A sender SHOULD NOT combine multiple entries unless they are all </del>  under the same organizational control and the hosts have already been <del> replaced by pseudonyms.  A sender MUST NOT combine entries that have </del>  different received-protocol values. 5.6.2.

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
the firewall by an appropriate pseudonym for that host. An intermediary MAY combine an ordered subsequence of Via header  <ins> field list members into a single member if the entries have identical </ins> received-protocol values.  For example, could be collapsed to  <ins> A sender SHOULD NOT combine multiple list members unless they are all </ins> under the same organizational control and the hosts have already been  <ins> replaced by pseudonyms.  A sender MUST NOT combine members that have </ins> different received-protocol values. 5.6.2.
Original text:
the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value. <del> A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </del>  For example, a response that contains

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value.  <ins> A Vary field value consisting of a list of field names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </ins> For example, a response that contains
Original text:
A <del> header field-value of "*" always fails to match. </del>  The stored response with matching selecting header fields is known as the selected response.

Reviewer comments:
That's
says: I think this should be:
Discussed in Basel. The current ABNF defines as a special value which only invokes the semantics when it's the entire field value; otherwise, it becomes a field name (since it's valid according to the field-name ABNF) and effectively gets ignored (since it's not going to be in normal requests). An alternative way of looking at it is to say that it's a special field name that, when it occurs anywhere in the Vary field value, it effectively turns off caching, no matter what the rest of the field value contains. Waiting for data to see what implementations do. Either way, this needs some examples in the spec, since it's so special.
See some results . It looks like all browser engines will turn off caching if `.
Duplicate of ? See also .
NAME shhh, we're trying to inflate our issue stats.

Revised text:
A  <ins> header field value containing a member "*" always fails to match. </ins> The stored response with matching selecting header fields is known as the selected response.
Original text:
by the recipient. When defining new connection options, specification authors ought to <del> survey existing field names and ensure that the new connection option does not share the same name as an already deployed field.  Defining a new connection option essentially reserves that potential field name for carrying additional information related to the connection option, since it would be unwise for senders to use that field name for anything else. </del>  The "

Reviewer comments:
We should explicitly tell them to reserve it.
I think the last comma is bad, but not enough to tweak it myself.

Revised text:
by the recipient. When defining new connection options, specification authors ought to  <ins> document it as reserved field name and register that definition in the Hypertext Transfer Protocol (HTTP) Field Name Registry (field.name.registry), to avoid collisions. </ins> The "
Original text:
12.1. <del> Please update the "Hypertext Transfer Protocol (HTTP) Field Registry" registry at <https://www.iana.org/assignments/http-fields> with the </del>  field names listed in the two tables of header.field.syntax. 12.2.

Reviewer comments:
We should explicitly tell them to reserve it.
I think the last comma is bad, but not enough to tweak it myself.

Revised text:
12.1.  <ins> Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the </ins> field names listed in the two tables of header.field.syntax. 12.2.
Original text:
A shared cache MUST NOT use a cached response to a request with an header field (header.authorization) to satisfy any subsequent request <del> unless a response directive that allows such responses to be stored is present. </del>  <del> In this specification, the following </del>  <del> response directives (cache-response-directive) have such an effect: must-revalidate, public, and s-maxage. </del>  3.3.

Reviewer comments:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Revised text:
A shared cache MUST NOT use a cached response to a request with an header field (header.authorization) to satisfy any subsequent request  <ins> unless the response contains a </ins>  <ins> field with a response directive (cache-response-directive) that allows it to be stored by a shared cache and the cache conforms to the requirements of that directive for that response. </ins>  <ins> In this specification, the following response directives have such an effect: must-revalidate (cache-response-directive.must-revalidate), public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). </ins> 3.3.
Original text:
not to be needed for single-entry lists). Although it has been back-ported to many implementations, some <del> HTTP/1.0 caches will not recognize or obey this directive.  Also, no- cache response directives with field names are often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </del>  5.2.2.4.

Reviewer comments:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Revised text:
not to be needed for single-entry lists). Although it has been back-ported to many implementations, some  <ins> HTTP/1.0 caches will not recognize or obey this directive.  Also, the qualified form of the directive is often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </ins> 5.2.2.4.
Original text:
8.1. <del> Please update the "Hypertext Transfer Protocol (HTTP) Field Registry" registry at <https://www.iana.org/assignments/http-fields> with the </del>  field names listed in the two tables of header.field.definitions. 8.2.

Reviewer comments:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Revised text:
8.1.  <ins> Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the </ins> field names listed in the two tables of header.field.definitions. 8.2.
Original text:
explicit expiration time F  fresh freshness lifetime

Reviewer comments:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Revised text:
explicit expiration time F <ins> Fields Age Cache-Control Expires Pragma Warning </ins> fresh freshness lifetime
Original text:
VCHAR H  heuristic expiration time heuristically cacheable

Reviewer comments:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Revised text:
VCHAR H <ins> Header Fields Age Cache-Control Expires Pragma Warning </ins> heuristic expiration time heuristically cacheable
Original text:
environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user <del> agent's behavior over time without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </del>  There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable

Reviewer comments:
… section;
Hi Roy, Please consider this reference for the privacy considerations section: Bujlow, T., Carela-Español, V., Solé-Pareta, J., & Barlet-Ros, P. (2017). A survey on web tracking: Mechanisms, implications, and defenses. Proceedings of the IEEE, 105(8), 1476–1510. Regards, Rob
URL
NAME has done a lot of work in this area, so he might have another suggestion. The referenced paper does cover a good amount of techniques that target HTTP itself, so I'd say that it's worth citing unless a better option presents itself.

Revised text:
environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user  <ins> agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </ins> There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable
Original text:
The "public" response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the <del> constraints of any other response directives present.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). </del>  <del> If no explicit freshness information is provided, the response is is heuristically cacheable (heuristic.freshness). </del>  5.2.2.7.

Reviewer comments:
NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.

Revised text:
The "public" response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the  <ins> constraints defined in response.cacheability.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). Note that it is not necessary to add the public directive to a response that is already cacheable according to response.cacheability. </ins>  <ins> If no explicit freshness information is provided on a response with the public directive, it is heuristically cacheable (heuristic.freshness). </ins> 5.2.2.7.