jiebi/TextFlow huggingface dataset:
Original text:
request: i.e., a response to a GET request, which contains a representation of the <del> resource identified by the request target (GET).  However, it is also possible to store redirects, negative results (e.g., </del>  ), incomplete results (e.g.,

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
request: i.e., a response to a GET request, which contains a representation of the  <ins> target resource (GET).  However, it is also possible to store redirects, negative results (e.g., </ins> ), incomplete results (e.g.,
Original text:
3.1. <del> A response message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is provided, a response message that is ended by the connection's close is considered complete even though it might be indistinguishable from an incomplete response (see Messaging).  A cache SHOULD consider a close-terminated response incomplete if the connection termination is detected to be an error.  A server that wishes to avoid premature termination resulting in an incorrect cached response SHOULD send the response with explicit framing. </del> If the request method is GET, the response status code is , and the entire response header section has been received, a cache <del> MAY store an incomplete response message body if the stored response is recorded as incomplete.  Likewise, a </del>  response MAY be stored as if it were an incomplete

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
3.1.  If the request method is GET, the response status code is , and the entire response header section has been received, a cache  <ins> MAY store a response body that is not complete (operation) if the stored response is recorded as being incomplete.  Likewise, a </ins> response MAY be stored as if it were an incomplete
Original text:
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request <del> using a stored response by copying the method, request-target, and </del>  request header fields identified by the Vary header field caching.negotiated.responses.

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request  <ins> using a stored response by copying the method, target URI, and </ins> request header fields identified by the Vary header field caching.negotiated.responses.
Original text:
stored response) or if transmission of the representation body is not desired even if it has changed. <del> When a cache makes an inbound HEAD request for a given request target and receives a </del>  response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
stored response) or if transmission of the representation body is not desired even if it has changed.  <ins> When a cache makes an inbound HEAD request for a given target URI and receives a </ins> response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see
Original text:
Because unsafe request methods (safe.methods) such as PUT, POST or DELETE have the potential for changing state on the origin server, <del> intervening caches can use them to keep their contents up to date. </del>  <del> A cache MUST invalidate the effective Request URI (effective.request.uri) as well as the URI(s) in the </del>  and

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
Because unsafe request methods (safe.methods) such as PUT, POST or DELETE have the potential for changing state on the origin server,  <ins> intervening caches are required to invalidate stored responses to keep their contents up to date. 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 that it travels through. </ins>  <ins> A cache MUST invalidate the target URI (target.resource) as well as the URI(s) in the </ins> and
Original text:
or response header field if the host part of that URI differs from the <del> host part in the effective request URI (effective.request.uri).  This helps prevent denial-of-service attacks. </del>  <del> A cache MUST invalidate the effective request URI (effective.request.uri) when it 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 or <del> status code.  "Invalidate" means that the cache will either remove all stored responses related to the effective request URI or will mark these 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.  For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not. </del>  5.

Reviewer comments:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Revised text:
or response header field if the host part of that URI differs from the  <ins> host part in the target URI (target.resource).  This helps prevent denial-of-service attacks. </ins>  <ins> A cache MUST invalidate the target URI (target.resource) when it receives a non-error response to a request with a method whose safety is unknown. </ins> Here, a "non-error response" is one with a or  <ins> status code. </ins> 5.
Original text:
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order: <del> Any extension to HTTP/1.1 that defines additional conditional request </del>  header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.

Reviewer comments:
header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice. This should just be "HTTP", no?

Revised text:
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:  <ins> Any extension to HTTP that defines additional conditional request </ins> header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.
Original text:
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding <del> of packets, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </del>  CONNECT is intended only for use in requests to a proxy.  An origin server that receives a CONNECT request for itself MAY respond with a

Reviewer comments:
The current section on CONNECT (7.3.6) in the semantics document refers to the proxy forwarding packets: Since the proxy terminates TCP, there is no forwarding of IP packets, but rather the contents of the TCP streams.
Well spotted! I'd even suggest "to blindly forward bytes in both directions ...". Too often I see people who imagine that packet delimitation is respected on both sides of a proxy and I have to tell them that it's just a uninterrupted stream of bytes that each layer decides to delimit wherever it wants.
I'd say that 7231 is self-consistent with the use of packet in 7230. If a change is needed, we should change wording consistently. Or, was this issue raised on the WIP core doc?
NAME this issue is being raised on the WIP core doc. The same text does also exist in 7231, but I consider them to both be in error. While we're updating the text for the core doc, let's fix the text to be clearer.
Thanks for the clarification NAME that sounds good to me.
Fwiw, the HiNT draft uses the terminology: blind forwarding of IP payloads, UDP datagram payloads and TCP/IP packet payload.
HTTP/3 says:
NAME that text looks good. Something along those lines, but that also works for HTTP/1.1, would be right for this core doc text.
Maybe just replace "packets" with "data"?
So as mentioned above in , while having a look at the latest draft I was struck again by this "packets" there, and even forgot about this old issue. Pinging again. I suggest that we change "forwarding of packets" with "forwarding of the byte stream" so that we can close these issues.

Revised text:
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding  <ins> of data, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </ins> CONNECT is intended only for use in requests to a proxy.  An origin server that receives a CONNECT request for itself MAY respond with a
Original text:
request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation).  If the field value is "*", the condition is false if the origin server does not have a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation. </del>  An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server

Reviewer comments:
URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?

Revised text:
request. An origin server that receives an If-Match header field MUST evaluate  <ins> the condition prior to performing the method (evaluation). To evaluate a received If-Match header field: </ins> An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server
Original text:
An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (evaluation). <del> If the field value is "*", the condition is false if the origin server has a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the selected representation. </del>  An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond

Reviewer comments:
URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?

Revised text:
An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (evaluation).  <ins> To evaluate a received If-None-Match header field: </ins> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond
Original text:
status code is similar to , but it indicates that the client needs to authenticate itself in <del> order to use a proxy.  The proxy MUST send a </del>  header field (field.proxy-authenticate) containing a challenge <del> applicable to that proxy for the target resource.  The client MAY repeat the request with a new or replaced </del>  header field (field.proxy-authorization).

Reviewer comments:
P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .

Revised text:
status code is similar to , but it indicates that the client needs to authenticate itself in  <ins> order to use a proxy for this request.  The proxy MUST send a </ins> header field (field.proxy-authenticate) containing a challenge  <ins> applicable to that proxy for the request.  The client MAY repeat the request with a new or replaced </ins> header field (field.proxy-authorization).
Original text:
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters <del> applicable to the proxy for this target URI (target.resource).  A proxy MUST send at least one Proxy-Authenticate header field in each </del>  response that it generates.

Reviewer comments:
P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .

Revised text:
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters  <ins> applicable to the proxy for this request.  A proxy MUST send at least one Proxy-Authenticate header field in each </ins> response that it generates.
Original text:
that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload.  A client MUST NOT send a request containing Transfer-Encoding unless it knows the <del> server will handle HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). </del>  A server that receives a request message with a transfer coding it does not understand SHOULD respond with

Reviewer comments:
These "(or laters)" don't seem to be accurate.
Suggest "(or later minor revisions of HTTP/1)"

Revised text:
that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload.  A client MUST NOT send a request containing Transfer-Encoding unless it knows the  <ins> server will handle HTTP/1.1 requests (or later minor revisions); such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later minor revisions). </ins> A server that receives a request message with a transfer coding it does not understand SHOULD respond with
Original text:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.  Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not

Reviewer comments:
changes to -messaging pulled from URL
I'll go ahead with this one as we already reached consensus in the original PR.

Revised text:
the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not
Original text:
account when creating a new HTTP field. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is <del> located at "https://www.iana.org/assignments/http-fields/". </del>  Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Fields with the status <del> 'permanent' are Specification Required (using terminology from RFC8126). </del>  Registration requests consist of at least the following information:  The Expert(s) can define additional fields to be collected in the registry, in consultation with the community.

Reviewer comments:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Revised text:
account when creating a new HTTP field. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is  <ins> located at <https://www.iana.org/assignments/http-fields/>. </ins> Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Fields with the status  <ins> 'permanent' are Specification Required (RFC8126). </ins> Registration requests consist of at least the following information: <ins> And, optionally: </ins> The Expert(s) can define additional fields to be collected in the registry, in consultation with the community.
Original text:
limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data.  Leading and trailing whitespace in raw field values is removed upon field parsing (field.parsing).  Field definitions where leading or trailing whitespace in values is significant will have to use a

Reviewer comments:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Revised text:
limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <ins> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (field.parsing).  Field definitions where leading or trailing whitespace in values is significant will have to use a
Original text:
request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation). </del>  To evaluate a received If-Match header field:

Reviewer comments:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Revised text:
request. An origin server that receives an If-Match header field MUST evaluate  <ins> the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-Match header field:
Original text:
initial representation for the target resource. An origin server that receives an If-None-Match header field MUST <del> evaluate the condition prior to performing the method (evaluation). </del>  To evaluate a received If-None-Match header field:

Reviewer comments:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Revised text:
initial representation for the target resource. An origin server that receives an If-None-Match header field MUST  <ins> evaluate the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-None-Match header field: