jiebi/TextFlow huggingface dataset:
Original text:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del>  HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del>  on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they  <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of  <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF
Original text:
9.1. <del> The permanent message header field registry (see RFC3864) needs to be </del>  updated with the following registration: Cookie

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
9.1.  <ins> The HTTP Field Name Registry (see HttpFieldNameRegistry) needs to be </ins> updated with the following registration: Cookie
Original text:
9.2. <del> The permanent message header field registry (see RFC3864) needs to be updated with the following registration: </del>  Set-Cookie

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
9.2.  <ins> The permanent message header field registry (see HttpFieldNameRegistry) needs to be updated with the following registration: </ins> Set-Cookie
Original text:
9.3. <del> IANA is requested to create the "Cookie Attribute Registry", defining </del>  the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
9.3.  <ins> IANA is requested to create the "Cookie Attribute" registry, defining </ins> the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].
Original text:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del>  2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del>  The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it

Reviewer comments:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Revised text:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are  <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification  <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it
Original text:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del>  Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Reviewer comments:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Revised text:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1  <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap
Original text:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del>  A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and

Reviewer comments:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Revised text:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as  <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and
Original text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del>  semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

Reviewer comments:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Revised text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers  <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
Original text:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del>  HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del>  on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF

Reviewer comments:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Revised text:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they  <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of  <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF
Original text:
encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. <del> The encoding of the public key is determined by the Signature </del>  Algorithm in use as follows: This document does not define the public key encodings for other

Reviewer comments:
In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.

Revised text:
encoding from QUIC and MUST be encoded in the minimum number of bytes necessary.  <ins> 3.1.1. Both the "Public Key" field of the TLS key exporter context (see above) and the "a" Parameter (see parameter-a) carry the same public key.  The encoding of the public key is determined by the Signature </ins> Algorithm in use as follows: This document does not define the public key encodings for other
Original text:
4.2. The REQUIRED "a" (public key) parameter is a byte sequence that <del> contains the public key used by the server to validate the signature </del>  provided by the client.  This avoids key confusion issues (see SEEMS- <del> LEGIT).  The encoding of the public key is described in context. </del>  4.3.

Reviewer comments:
In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.

Revised text:
4.2. The REQUIRED "a" (public key) parameter is a byte sequence that  <ins> specifies the public key used by the server to validate the signature </ins> provided by the client.  This avoids key confusion issues (see SEEMS-  <ins> LEGIT).  The encoding of the public key is described in public-key- encoding. </ins> 4.3.
Original text:
4.1. <del> The REQUIRED "k" (key ID) parameter is a byte sequence that </del>  identifies which key the client wishes to use to authenticate.  This can, for example, be used to point to an entry in a server-side database of known keys. 4.2. <del> The REQUIRED "a" (public key) parameter is a byte sequence that </del>  specifies the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in public-key-

Reviewer comments:
The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter

Revised text:
4.1.  <ins> The REQUIRED "k" (key ID) Parameter is a byte sequence that </ins> identifies which key the client wishes to use to authenticate.  This can, for example, be used to point to an entry in a server-side database of known keys. 4.2.  <ins> The REQUIRED "a" (public key) Parameter is a byte sequence that </ins> specifies the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in public-key-
Original text:
4.3. <del> The REQUIRED "p" (proof) parameter is a byte sequence that specifies </del>  the proof that the client provides to attest to possessing the credential that matches its key ID. 4.4. <del> The REQUIRED "s" (signature) parameter is an integer that specifies </del>  the signature scheme used to compute the proof transmitted in the "p" <del> directive.  Its value is an integer between 0 and 65535 inclusive </del>  from the IANA "TLS SignatureScheme" registry maintained at <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. 4.5. <del> The REQUIRED "v" (verification) parameter is a byte sequence that </del>  specifies the verification that the client provides to attest to possessing the key exporter output (see output for details).  This avoids issues with signature schemes where certain keys can generate

Reviewer comments:
The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter

Revised text:
4.3.  <ins> The REQUIRED "p" (proof) Parameter is a byte sequence that specifies </ins> the proof that the client provides to attest to possessing the credential that matches its key ID. 4.4.  <ins> The REQUIRED "s" (signature) Parameter is an integer that specifies </ins> the signature scheme used to compute the proof transmitted in the "p"  <ins> Parameter.  Its value is an integer between 0 and 65535 inclusive </ins> from the IANA "TLS SignatureScheme" registry maintained at <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. 4.5.  <ins> The REQUIRED "v" (verification) Parameter is a byte sequence that </ins> specifies the verification that the client provides to attest to possessing the key exporter output (see output for details).  This avoids issues with signature schemes where certain keys can generate
Original text:
the presence of authentication to observers due to clear-text TLS Client Hello extensions.  The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication proofs on multiple requests on the same connection, they will all be

Reviewer comments:
In Section 8: Given that the exporter can be produced at any point in the lifetime of a TLS connection and that TLS connections can remain open for a very long time, it's not clear that this guarantees freshness in the same way that a nonce does. It might be clearer to state that it guarantees the authenticator is no older than the beginning of the current TLS connection. (I presume that a server can use GOAWAY to get rid of connections it considers unacceptably old.)

Revised text:
the presence of authentication to observers due to clear-text TLS Client Hello extensions. <ins> Since the freshness described above is provided by a TLS key exporter, it can be as old as the underlying TLS connection.  Servers can require better freshness by forcing clients to create new connections using mechanisms such as the GOAWAY frame (see H3). </ins> The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication proofs on multiple requests on the same connection, they will all be
Original text:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar:  Servers MUST be tolerant of multiple cookie headers.  For example, an <del> HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </del>  4.2.2.

Reviewer comments:
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.

Revised text:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> While Section 5.4 of RFC9110 does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8K.  Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit.  Not doing so could result in requests to the server failing. </ins> Servers MUST be tolerant of multiple cookie headers.  For example, an  <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114 client or intermediary might split a cookie header to improve compression.  Servers are free to determine what form this tolerance takes.  For example, the server could process each cookie header individually or the server could concatenate all the cookie headers into one and then process that final, single, header.  The server should be mindful of any header field limits when deciding which approach to take. Note: Since intermediaries can modify cookie headers they should also be mindful of common server header field limits in order to avoid sending servers headers that they cannot process.  For example, concatenating multiple cookie headers into a single header might exceed a server's size limit. </ins> 4.2.2.
Original text:
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP".  5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to

Reviewer comments:
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.

Revised text:
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to