jiebi/TextFlow huggingface dataset:
Original text:
be sent along with "same-site" requests.  If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in strict-lax.  If the "SameSite" <del> attribute's value is neither of these, the cookie will be ignored. </del>  4.1.3.

Reviewer comments:
There is currently a discrepancy in the spec regarding invalid values in the SameSite cookie attribute. For example, this cookie: Set-Cookie: foo=bar; SameSite=bogus is expected to be dropped entirely according to the "Server Requirements" under Section 4.1.2.7: If the "SameSite" attribute's value is neither of these [ "Lax", "Strict" ], the cookie will be ignored. whereas under Section 5.3.7 of "User Agent Requirements", the cookie is to be kept but the attribute is ignored: If cookie-av's attribute-value is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av". Additionally, the end of Section 4.1.2 also matches the behavior described in Section 5.3.7: User agents ignore unrecognized cookie attributes (but not the entire cookie). From a forward-compatibility point of view, the behavior described in section 5.3.7 is the ideal one since it allows for future expansion of this feature such as: Set-Cookie: foo=bar; SameSite=medium
NAME
Done. Let me know if I missed anything else.
URL Section 3.1 of the spec states that "SameSite" alone (without an attribute value) is a valid token: URL Section 4.1 URL states If "cookie-av"'s "attribute-value" is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av".
Ah. URL draft is outdated vs. URL The latter no longer allows a bare "SameSite" token, and it calls for the cookie to be dropped in the event that the samesite-value isn't either "strict" or "lax". However, I think this text isn't quite right: If 's is not a case-insensitive match for "Strict" or "Lax", ignore the . The in this case is 'SameSite=whatever' and we want to ignore the whole cookie, not just the invalid attribute?
is my proposal to fix this. We ran into this issue in the Firefox implementation: URL
Thanks!

Revised text:
be sent along with "same-site" requests.  If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in strict-lax.  If the "SameSite"  <ins> attribute's value is neither of these, the attribute will be ignored. </ins> 4.1.3.
Original text:
where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD <del> request, as described above. </del>  In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client

Reviewer comments:
Also considering if "Security Considerations" can be "Compatibility Considerations".
I haven't renamed "Security Considerations" in this version. And I have no issue with calling this "Compatibility Considerations". But I have some recollection that this is a required section...
Yeah don't do that or various people will start to scream at you :)
Call me a perfectionist, but on reread, I realized there was a cleaner/shorter way to clarify. Let me know if you have any objection...
Thanks Martin!

Revised text:
where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD  <ins> request, as described above, and much larger than the expected maximum size of the representation.  See Security for range value considerations. </ins> In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client
Original text:
(see be-consistent for details). An intermediary MUST NOT remove this header field if it is present in <del> a request. </del>  The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in

Reviewer comments:
According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.

Revised text:
(see be-consistent for details). An intermediary MUST NOT remove this header field if it is present in  <ins> a request.  "Early-Data" MUST NOT appear in a "Connection" header field. </ins> The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in
Original text:
be safely processed MUST be rejected using the 425 (Too Early) status code.  5.2. A 425 (Too Early) status code indicates that the server is unwilling

Reviewer comments:
According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.

Revised text:
be safely processed MUST be rejected using the 425 (Too Early) status code. <ins> The "Early-Data" header field carries a single bit of information and clients MUST include at most one instance.  Multiple instances MUST be treated as equivalent to a single instance by a server. A "Early-Data" header field MUST NOT be included in responses or request trailers. </ins> 5.2. A 425 (Too Early) status code indicates that the server is unwilling
Original text:
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can choose whether it will process early data before the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </del>  assurance that the early data was not replayed. If the server receives multiple requests in early data, it can

Reviewer comments:
Our basic list of mitigations missed a fairly obvious one. Mentioning it should help with the class of confusion Magnus N. had with the draft. I decided not to include a note about the server being unable to examine early data before making this decision. That's just something people will need to discover for themselves. Generally, you have to decide whether you want 0-RTT without seeing any of it. Partly this is because it avoids a potential deadlock, but mostly it's because the TLS stack will not even decrypt 0-RTT if it is rejected.
Looks good to me, and indeed clearer. Thanks.
+1

Revised text:
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays.  <ins> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </ins> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can
Original text:
data MUST be sent again, unless the client decides to abandon those requests. <del> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that accepts and processes the early data, but allows that connection to proceed no further.  The attacker then forwards the same messages from the client to another server instance that will reject early data.  The client then retries the request, resulting in the request being processed twice.  Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del>  Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.

Reviewer comments:
This was a little obtuse in the previous iteration, likely as a result of trying to be parsimonious. Expand it a little and clarify the attack.
It's indeed better like this in my opinion.

Revised text:
data MUST be sent again, unless the client decides to abandon those requests.  <ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.
Original text:
2.1.4. <del> The following examples demonstrate valid Expect-CT response header fields: </del>  2.2.

Reviewer comments:
URL too wide artwork by changing the second example to use multiple field instances (which, in itself, is good to have in the examples anyway)
Thanks!

Revised text:
2.1.4.  <ins> The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances): </ins> 2.2.
Original text:
<del> The Tunnel-Protocol HTTP Header Field </del>  draft-ietf-httpbis-tunnel-protocol-latest Abstract This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the <del> Tunnel-Protocol header field. </del>  Editorial Note (To be removed by RFC Editor)

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Revised text:
 <ins> The ALPN HTTP Header Field </ins> draft-ietf-httpbis-tunnel-protocol-latest Abstract This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the  <ins> ALPN header field. </ins> Editorial Note (To be removed by RFC Editor)
Original text:
Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies. <del> The HTTP Tunnel-Protocol header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </del>  <del> When the CONNECT method is used to establish a tunnel, the Tunnel- Protocol header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </del>  protocols are indicated. <del> The Tunnel-Protocol header field carries an indication of client intent only.  In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other protocols could negotiate protocols differently. </del>  Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Revised text:
Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies.  <ins> The HTTP ALPN header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </ins>  <ins> When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </ins> protocols are indicated.  <ins> The ALPN header field carries an indication of client intent only. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client.  Other protocols could negotiate protocols differently. </ins> Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header
Original text:
2. <del> Clients include the Tunnel-Protocol header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </del>  2.1.

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

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

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Revised text:
2.2.  <ins> The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) MUST
Original text:
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- <del> headers>.  This document defines and registers the Tunnel-Protocol header field, according to RFC3864 as follows: </del>  <del> Tunnel-Protocol </del>  http

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Revised text:
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message-  <ins> headers>.  This document defines and registers the ALPN header field, according to RFC3864 as follows: </ins>  <ins> ALPN </ins> http
Original text:
Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </del>  indistinguishable from the case where either client or proxy does not <del> support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> 

Reviewer comments:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Revised text:
Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."  <ins> The ALPN header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </ins> indistinguishable from the case where either client or proxy does not  <ins> support the ALPN header field. The value of the ALPN header field could be falsified by a client. If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the ALPN header field as a policy input in all cases. </ins>
Original text:
HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from.  The traditional form of server authentication in HTTP has been <del> in the form of a single X.509 certificate provided during the TLS I- D.ietf-tls-tls13 handshake. </del>  Many existing HTTP RFC7230 servers also have authentication requirements for the resources they serve.  Of the bountiful

Reviewer comments:
They were both special, but for some reason the first reference wasn't getting brackets in the text output. Putting whitespace between them doesn't affect that, but putting other characters does.
LGTM. (And yes, I tried whitespace as well :-)

Revised text:
HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from.  The traditional form of server authentication in HTTP has been  <ins> in the form of a single X.509 certificate provided during the TLS (RFC5246, I-D.ietf-tls-tls13) handshake. </ins> Many existing HTTP RFC7230 servers also have authentication requirements for the resources they serve.  Of the bountiful
Original text:
TLS 1.3 TLS13 introduces the concept of early data (also known as zero round trip data or 0-RTT data).  Early data allows a client to send data to a server in the first round trip of a connection, <del> without waiting for the TLS handshake to complete if the client has </del>  spoken to the same server recently. When used with HTTP HTTP, early data allows clients to send requests

Reviewer comments:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Revised text:
TLS 1.3 TLS13 introduces the concept of early data (also known as zero round trip data or 0-RTT data).  Early data allows a client to send data to a server in the first round trip of a connection,  <ins> without waiting for the TLS handshake to complete, if the client has </ins> spoken to the same server recently. When used with HTTP HTTP, early data allows clients to send requests
Original text:
request routing is likely to be safe from side-effects, but other actions might not be. <del> Intermediary servers do not have sufficient information to make this determination, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism. </del>  Note that a server cannot choose to selectively reject early data at the TLS layer.  TLS only permits a server to accept all early data,

Reviewer comments:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Revised text:
request routing is likely to be safe from side-effects, but other actions might not be.  <ins> Intermediary servers do not have sufficient information to decide whether early data can be processed, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data.  Intermediaries that accept early data MUST implement that mechanism. </ins> Note that a server cannot choose to selectively reject early data at the TLS layer.  TLS only permits a server to accept all early data,
Original text:
sent in early data - thereby giving the client control over risk of replay.  Absent other information, clients MAY send requests with safe HTTP methods (see RFC7231, Section 4.2.1) in early data when it <del> is available, and SHOULD NOT send unsafe methods (or methods whose </del>  safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST

Reviewer comments:
NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!

Revised text:
sent in early data - thereby giving the client control over risk of replay.  Absent other information, clients MAY send requests with safe HTTP methods (see RFC7231, Section 4.2.1) in early data when it  <ins> is available, and MUST NOT send unsafe methods (or methods whose </ins> safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST