jiebi/TextFlow huggingface dataset:
Original text:
RFC8126) and MUST conform to the purpose of content coding defined in content.codings.  7.1.3. A language tag, as defined in RFC5646, identifies a natural language

Reviewer comments:
As part of the discussion about the Encryption specification we discussed how Content-Encodings can or should take parameters from HTTP headers. The consensus was that they shouldn't. Whatever information a C-E may need should be inside the body of the object, just like the GZIP header etc. We should document this as a rule, if we ever do a HTTP[1].ter
+1, except for the constraint: "when possible". In the case of the encryption coding, it's clearly necessary to have the actual key information needed for description outside the payload.
we can add something to URL
I'm fine with this, but I'm also fine with closing with no action. I'm not sure what value it's really adding, since it's so vague, but I'm not sure what else can be said.

Revised text:
RFC8126) and MUST conform to the purpose of content coding defined in content.codings. <ins> New content codings ought to be self-descriptive whenever possible, with optional parameters discoverable within the coding format itself, rather than rely on external metadata that might be lost during transit. </ins> 7.1.3. A language tag, as defined in RFC5646, identifies a natural language
Original text:
7.2.4.  An example is A sender MUST NOT send a Content-Length header field in any message

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
7.2.4. <ins> The "Content-Length" header field indicates the associated representation's data length as a decimal non-negative integer number of octets.  When transferring a representation in a message, Content- Length refers specifically to the amount of data enclosed so that it can be used to delimit framing of the message body (e.g., body.content-length).  In other cases, Content-Length indicates the selected representation's current length, which can be used by recipients to estimate transfer time or compare to previously stored representations. </ins> An example is A sender MUST NOT send a Content-Length header field in any message
Original text:
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del>  <del> does not match one already stored (or partially stored) from a prior request. </del>  An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to  <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins>  <ins> does not match one that the client has already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.
Original text:
To evaluate a received If-Match header field: An origin server MUST NOT perform the requested method if a received <del> If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del>  The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
To evaluate a received If-Match header field: An origin server MUST NOT perform the requested method if a received  <ins> If-Match condition evaluates to false.  Instead, the origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  For example, multiple user agents writing to a common resource as a semaphore (e.g., a non-atomic increment) are likely to collide and potentially lose important state transitions.  For those kinds of resources, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method.  In other cases, excluding the ETag field from a success response might encourage the user agent to perform a GET as its next request to eliminate confusion about the resource's current state. </ins> The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
Original text:
. A recipient MUST ignore the If-Unmodified-Since header field if the <del> received field value is not a valid HTTP-date, or if the field value has more than one member. </del>  A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
. A recipient MUST ignore the If-Unmodified-Since header field if the  <ins> received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.
Original text:
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del>  <del> does not match one already stored (or partially stored) from a prior request. </del>  An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to  <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins>  <ins> does not match one that the client already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the
Original text:
If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the <del> origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del>  The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the  <ins> origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  In those cases, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. </ins> The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
Original text:
.  If a 206 is generated in response to a request with an header field, the sender SHOULD NOT generate other representation

Reviewer comments:
We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?

Revised text:
. <ins> A field present in a 206 response indicates the number of octets in the body of this message, which is usually not the complete length of the selected representation.  Each field includes information about the selected representation's complete length. </ins> If a 206 is generated in response to a request with an header field, the sender SHOULD NOT generate other representation
Original text:
Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully <del> performed its normal request checks and just before it would perform the action associated with the request method.  A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a </del>  or <del> .  In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests. </del>  A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT

Reviewer comments:
reads: This seems to have the effect that 412 cannot happen as part of a 100-continue response, but instead, the entire upload body must be parsed for errors (such as ), and only if it is free of errors can the server return 412 (Precondition Failed). This seems unnecessary and wasteful of bandwidth, and perhaps a result of the fact that server-side validation of documents, including the 422 Unprocessable Entity status code, is a comparatively newer feature of HTTP servers. [1] If this is the case, consider relaxing this requirement so that 412 (Precondition Failed) is the last error tested before the request body is parsed. [1] See mailing list thread:

Revised text:
Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully  <ins> performed its normal request checks and just before it would process the request body (if any) or perform the action associated with the request method.  A server MUST ignore all received preconditions if its response to the same request without those conditions, prior to processing the request body, would have been a status code other than a </ins> or  <ins> .  In other words, redirects and failures that can be detected before significant processing occurs take precedence over the evaluation of preconditions. </ins> A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT
Original text:
doing so (e.g., qvalues on and similar request header fields), that mechanism MAY be used to <del> select preferred responses; of the remainder, the most recent response (as determined by the </del>  header field) is used, as per constructing.responses.from.caches. <del> Note that in practice, some resources might send the Vary header field on responses inconsistently.  When a cache has multiple responses for a target URI, and one or more omits the Vary header field, it SHOULD use the most recent non-empty value available to select an appropriate response for the request. </del>  If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server

Reviewer comments:
Need to talk about the on-the-wire scenarios; representation w/ vary vs without.
When making the edit above, I started to wonder what the best strategy was to recommend: Use the most recent valid Vary field value (current text) Just give the one without a Vary field value the lowest priority Thoughts NAME NAME ?
This language is a bit ambiguous regarding whether the received response is included in those considered, etc.
On second reading this wasn't as bad as I thought; made a few small editorial clarifications.

Revised text:
doing so (e.g., qvalues on and similar request header fields), that mechanism MAY be used to  <ins> select a preferred response.  If such a mechanism is not available, or leads to equally preferred responses, the most recent response (as determined by the </ins> header field) is used, as per constructing.responses.from.caches.  <ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), selecting it for requests to that resource even when more preferable responses are available.  When a cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </ins> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server
Original text:
3.1. <del> Caches MUST include all received header fields -- including </del>  unrecognised ones -- when storing a response; this assures that new HTTP header fields can be successfully deployed.  However, the following exceptions are made:

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
3.1.  <ins> Caches MUST include all received response header fields -- including </ins> unrecognised ones -- when storing a response; this assures that new HTTP header fields can be successfully deployed.  However, the following exceptions are made:
Original text:
When there is more than one value present for a given directive (e.g., two <del> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid.  Caches are encouraged to consider responses that have invalid freshness information to be stale. </del>  4.2.2.

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
When there is more than one value present for a given directive (e.g., two  <ins> header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used, or the response should be considered stale.  If directives conflict (e.g., both max-age and no- cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale. </ins> 4.2.2.
Original text:
according to the calculations in expiration.model. A cache MUST NOT generate a stale response if it is prohibited by an <del> explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </del>  applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive).

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
according to the calculations in expiration.model. A cache MUST NOT generate a stale response if it is prohibited by an  <ins> explicit in-protocol directive (e.g., by a "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </ins> applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive).
Original text:
intervening caches are required to invalidate stored responses to keep their contents up to date. <del> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </del> A cache MUST invalidate the target URI (target.resource) and the URI(s) in the

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
intervening caches are required to invalidate stored responses to keep their contents up to date.  A cache MUST invalidate the target URI (target.resource) and the URI(s) in the
Original text:
receives a non-error response to a request with a method whose safety is unknown. <del> Here, a "non-error response" is one with a </del>  or status code.  5. This section defines the syntax and semantics of HTTP fields related

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
receives a non-error response to a request with a method whose safety is unknown.  <ins> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. A "non-error response" is one with a </ins> or status code. <ins> Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </ins> 5. This section defines the syntax and semantics of HTTP fields related
Original text:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del>  The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
age.calculations. The Age field value is a non-negative integer, representing time in  <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Original text:
Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the <del> field names listed in the two tables of header.field.definitions. </del>  8.2.

Reviewer comments:
: I think that MAY should be prose, and should also list retrying the request as an option.

Revised text:
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 table in header.field.definitions. </ins> 8.2.