jiebi/TextFlow huggingface dataset:
Original text:
4. <del> Section 9.2.1 of RFC7540 does not extend to TLS 1.3 KeyUpdate messages.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. </del>  5. <del> This document clarifies how to use HTTP/2 with TLS 1.3 and resolves a compatibility concern when supporting post-handshake authentication with HTTP/1.1.  This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.  Permitting key updates allows key material to be refreshed in long-lived HTTP/2 connections. </del>  6.

Reviewer comments:
This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.

Revised text:
4.  <ins> RFC8446 defines two other messages that are exchanged after the handshake is complete, KeyUpdate and NewSessionTicket. KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. NewSessionTicket messages are also permitted.  Though these interact with HTTP when early data is enabled, these interactions are defined in RFC8470 and allowed for in the design of HTTP/2. Unless the use of a new type of TLS message depends on an interaction with the application layer protocol, that TLS message can be sent after the handshake completes. </ins> 5.  <ins> This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2. </ins> 6.
Original text:
HTTP/2 RFC7540 multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above.  Clients cannot correlate the certificate request with the HTTP request which <del> triggered it.  Thus, section 9.2.1 of RFC7540 forbids renegotiation. </del>  TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms.

Reviewer comments:
(Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL

Revised text:
HTTP/2 RFC7540 multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above.  Clients cannot correlate the certificate request with the HTTP request which  <ins> triggered it.  Thus, Section 9.2.1 of RFC7540 forbids renegotiation. </ins> TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms.
Original text:
HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- <del> handshake authentication as a connection error (see section 5.4.1 of </del>  RFC7540) of type PROTOCOL_ERROR. RFC7540 permitted renegotiation before the HTTP/2 connection preface

Reviewer comments:
(Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL

Revised text:
HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post-  <ins> handshake authentication as a connection error (see Section 5.4.1 of </ins> RFC7540) of type PROTOCOL_ERROR. RFC7540 permitted renegotiation before the HTTP/2 connection preface
Original text:
Here is a gzip-compressed json object  Now the same payload body conveys a malformed json object.  A Range-Request alters the payload body, conveying a partial representation.  Now the method too alters the payload body.  3. Digest algorithm values are used to indicate a specific digest

Reviewer comments:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Revised text:
Here is a gzip-compressed json object <ins> Request: </ins> Now the same payload body conveys a malformed json object. <ins> Request: </ins> A Range-Request alters the payload body, conveying a partial representation. <ins> Request: Response: </ins> Now the method too alters the payload body. <ins> Request: Response: </ins> 3. Digest algorithm values are used to indicate a specific digest
Original text:
7.1.1.  7.1.2. As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values are the same.  7.1.3.  7.1.4. Digest can be used in requests too.  Returned value depends on the representation metadata header fields.  7.1.5. Request "Digest" value is calculated on the enclosed payload.

Reviewer comments:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Revised text:
7.1.1. <ins> Request: Response: </ins> 7.1.2. As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values are the same. <ins> Request: Response: </ins> 7.1.3. <ins> Request: Response: </ins> 7.1.4. Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> Request: Response: </ins> 7.1.5. Request "Digest" value is calculated on the enclosed payload.
Original text:
one taking into account the "Content-Encoding".  7.2. 7.2.1.

Reviewer comments:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Revised text:
one taking into account the "Content-Encoding". <ins> Request: Response: </ins> 7.2. 7.2.1.
Original text:
The client requests a digest, preferring sha.  The server is free to reply with sha-256 anyway.  7.2.2. The client requests a sha digest only.  The server is currently free to reply with a Digest containing an unsupported algorithm  7.2.3. The client requests a sha Digest, the server advises for sha-256 and sha-512  ... 8.

Reviewer comments:
Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages

Revised text:
The client requests a digest, preferring sha.  The server is free to reply with sha-256 anyway. <ins> Request: Response: </ins> 7.2.2. The client requests a sha digest only.  The server is currently free to reply with a Digest containing an unsupported algorithm <ins> Request: Response: </ins> 7.2.3. The client requests a sha Digest, the server advises for sha-256 and sha-512 <ins> Request: Response: </ins> ... 8.
Original text:
RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del>  in this document are to be interpreted as described in RFC7230 and RFC7231.  2. To avoid inconsistencies, an integrity mechanism for HTTP messages

Reviewer comments:
to use the new "validator" name. See: URL URL
NAME I'm quite weak on that side: is this PR correct? If not feel free to fix at will :)
NAME I agree... this comes from the original RFC 3230. Merging the change as a simple terminology update. The relation b/w validators and the resource is discussed in , where I tagged you as your guidance will be great. See too.
to clarify the following passage for defining the behavior of digest with caching (eg. when Digest is returned together with Last-Modified and ETag). and to better extend the definition of Digest to POST and PATCH requests. This is because though only when they include explicit freshness information. If we go on the new http-core definition (which is cleaner) we have that eg. According to URL POST responses identify returned resources in different ways according to the following: the primary resource is identified by Content-Location the enclosed representation matches the primary resource eg. 1 eg. 2 primary resource identified by enclosed representation matches the status of the request according to the resource's own semantic eg.
re-reading the old RFC my understanding is that validator fields should just be aligned with Digest (that is: digest-value should be aligned with the values of last-modified and etag). While it is trivial, the original editor could have considered that a potential issue.
The change itself looks right. I wonder however about the whole paragraph: what does it mean to say "resource is specified"? Doesn't that also need request header fields upon which the returned representation varies?

Revised text:
RFC7230. The definitions "representation", "selected representation",  <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages
Original text:
or not at all contained in the message body. <del> The resource is specified by the effective request URI and any cache- validator contained in the message. </del>  For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been

Reviewer comments:
to use the new "validator" name. See: URL URL
NAME I'm quite weak on that side: is this PR correct? If not feel free to fix at will :)
NAME I agree... this comes from the original RFC 3230. Merging the change as a simple terminology update. The relation b/w validators and the resource is discussed in , where I tagged you as your guidance will be great. See too.
to clarify the following passage for defining the behavior of digest with caching (eg. when Digest is returned together with Last-Modified and ETag). and to better extend the definition of Digest to POST and PATCH requests. This is because though only when they include explicit freshness information. If we go on the new http-core definition (which is cleaner) we have that eg. According to URL POST responses identify returned resources in different ways according to the following: the primary resource is identified by Content-Location the enclosed representation matches the primary resource eg. 1 eg. 2 primary resource identified by enclosed representation matches the status of the request according to the resource's own semantic eg.
re-reading the old RFC my understanding is that validator fields should just be aligned with Digest (that is: digest-value should be aligned with the values of last-modified and etag). While it is trivial, the original editor could have considered that a potential issue.
The change itself looks right. I wonder however about the whole paragraph: what does it mean to say "resource is specified"? Doesn't that also need request header fields upon which the returned representation varies?

Revised text:
or not at all contained in the message body.  <ins> The resource is specified by the effective request URI and any "validator" contained in the message. </ins> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been
Original text:
Extra Parameters: None. <del> Recommended HTTP status code: </del>  3.13.

Reviewer comments:
Rationale for 503 is that the service is unavailable due to too many connections. 429 could potentially be an option as well, but that seems more specific to a single user hitting a rate limit, while seems more related to a global limit. /cc NAME NAME

Revised text:
Extra Parameters: None.  <ins> Recommended HTTP status code: 503 </ins> 3.13.
Original text:
RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del>  in this document are to be interpreted as described in RFC7230 and RFC7231.  2. To avoid inconsistencies, an integrity mechanism for HTTP messages

Reviewer comments:
Replaces the old with from URL The relations of Last-Modified and ETag with Digest are examined in

Revised text:
RFC7230. The definitions "representation", "selected representation",  <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages
Original text:
or not at all contained in the message body. <del> The resource is specified by the effective request URI and any cache- validator contained in the message. </del>  For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been

Reviewer comments:
Replaces the old with from URL The relations of Last-Modified and ETag with Digest are examined in

Revised text:
or not at all contained in the message body.  <ins> The resource is specified by the effective request URI and any "validator" contained in the message. </ins> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been
Original text:
calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del>  A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in

Reviewer comments:
Clarifies the "returned value" expression.
There are two occurences of the fragment This is not the most helpful of statements, when we say "returned value" what exactly are we trying to convey. I think it would help to be a bit more exact.
Thanks. Longer term, I'd like to do an broad editorial sweep to tighten up document and this is an enabling step that I think this takes us most of the way there. I made some suggestions to move words around a bit.

Revised text:
calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET.  <ins> Digest can be used in requests too. The "Digest" value depends on the representation metadata. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
Original text:
9.4. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del>  Request:

Reviewer comments:
Clarifies the "returned value" expression.
There are two occurences of the fragment This is not the most helpful of statements, when we say "returned value" what exactly are we trying to convey. I think it would help to be a bit more exact.
Thanks. Longer term, I'd like to do an broad editorial sweep to tighten up document and this is an enabling step that I think this takes us most of the way there. I made some suggestions to move words around a bit.

Revised text:
9.4.  <ins> The request contains a "Digest" header calculated on the enclosed representation. It also includes an "Accept-Encoding: br" header field that advertises the client supports brotli encoding. The response includes a "Content-Encoding: br" that indicates the selected representation is brotli encoded.  The "Digest" field-value is therefore different compared to the request. </ins> Request:
Original text:
HTTP Client Hints <del> draft-ietf-httpbis-client-hints-07 </del>  Abstract

Reviewer comments:
I want to republish the CH draft as it expired, and the change logs didn't include a bunch of the recent changes. NAME NAME - Can you take a look?

Revised text:
HTTP Client Hints  <ins> draft-ietf-httpbis-client-hints-08 </ins> Abstract
Original text:
service can be used for establishing new connections, not limiting the use of existing ones.  When alternative services are used to send a client to the most optimal server, a change in network configuration can result in cached values becoming suboptimal.  Therefore, clients

Reviewer comments:
An alternate can send an Alt-Svc field that overrides that sent by the origin and is cached on an equal basis.

Revised text:
service can be used for establishing new connections, not limiting the use of existing ones. <ins> Alternative services are fully authoritative for the origin in question, including the ability to clear or update cached alternative service entries, extend freshness lifetimes, and any other authority the origin server would have. </ins> When alternative services are used to send a client to the most optimal server, a change in network configuration can result in cached values becoming suboptimal.  Therefore, clients
Original text:
The following examples show how representation metadata, payload transformations and method impacts on the message and payload body.  Here is a gzip-compressed json object

Reviewer comments:
clarify editorial rendering of binary payloads
in this example (and other), URL something like that:

Revised text:
The following examples show how representation metadata, payload transformations and method impacts on the message and payload body. <ins> When the payload body contains non-printable characters (eg. when it is compressed) it is shown as base64-encoded string. </ins> Here is a gzip-compressed json object
Original text:
selected representation is brotli encoded.  The "Digest" field-value is therefore different compared to the request.  Request: Response:

Reviewer comments:
clarify editorial rendering of binary payloads
in this example (and other), URL something like that:

Revised text:
selected representation is brotli encoded.  The "Digest" field-value is therefore different compared to the request. <ins> The response body is displayed as a base64-encoded string because it contains non-printable characters. </ins> Request: Response:
Original text:
3.2. Dictionaries are ordered maps of name-value pairs, where the names <del> are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </del>  Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the

Reviewer comments:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Revised text:
3.2. Dictionaries are ordered maps of name-value pairs, where the names  <ins> are short, textual strings and the values can be items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the
Original text:
whitespace, while names and values are separated by "=" (without whitespace).  For example:  A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with

Reviewer comments:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Revised text:
whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with