jiebi/TextFlow huggingface dataset:
Original text:
guidelines for the creation of such headers, colloquially known as "Client Hints." <del> It also defines an initial set of Client Hints. </del> Note to Readers Discussion of this draft takes place on the HTTP working group

Reviewer comments:
Tweak/cleanup in light of
NAME or NAME can you push the green button?
LGTM!

Revised text:
guidelines for the creation of such headers, colloquially known as "Client Hints."  Note to Readers Discussion of this draft takes place on the HTTP working group
Original text:
6.3. <del> Failure to provide a certificate on a stream after receiving </del>  "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to standard timeouts used to guard against unresponsive peers.

Reviewer comments:
and filed by NAME Given , the AUTOMATIC_USE text is entirely superfluous, and given , the correct wording would be "for a stream."
Not sure if this is an issue or not. Emphasis added in the below quote. This seems to have been left out of the change to stream 0 for all frames (URL)
Section 5.4 contains some left over text that refers to the now removed AUTOMATIC_USE flag. Cf. URL

Revised text:
6.3.  <ins> Failure to provide a certificate for a stream after receiving </ins> "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to standard timeouts used to guard against unresponsive peers.
Original text:
Name: http_response_status <del> Description: The intermediary has received a 4xx or 5xx status code from the next hop and forwarded it to the client. </del>  Extra Parameters: None.

Reviewer comments:
Signed-off-by: Piotr Sikora
This is effectively editorial, since the error restriction was removed in URL, where this type was renamed from to , but the description didn't reflect that change. cc NAME

Revised text:
Name: http_response_status  <ins> Description: The intermediary has received a response from the next hop and forwarded it to the client. </ins> Extra Parameters: None.
Original text:
For each member mem of input_plist: <del> Let id be the result of applying Serializing a Token (ser- token) to mem's token. </del>  <del> Append id to output. </del>  For each parameter in mem's parameters:

Reviewer comments:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Revised text:
For each member mem of input_plist:  <ins> Let item be the result of applying Serializing an item (ser- item) to mem's primary-item. </ins>  <ins> Append item to output. </ins> For each parameter in mem's parameters:
Original text:
4.2.4. Given an ASCII string input_string, return a list of parameterized <del> identifiers. input_string is modified to remove the parsed value. </del>  Let items be an empty array. While input_string is not empty: <del> Let item be the result of running Parse Parameterized Identifier from Text (parse-param-id) with input_string. </del>  Append item to items.

Reviewer comments:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Revised text:
4.2.4. Given an ASCII string input_string, return a list of parameterized  <ins> items. input_string is modified to remove the parsed value. </ins> Let items be an empty array. While input_string is not empty:  <ins> Let item be the result of running Parse Parameterized Item from Text (parse-param-item) with input_string. </ins> Append item to items.
Original text:
map of parameters. input_string is modified to remove the parsed value. <del> Let primary_identifier be the result of Parsing a Token from Text (parse-token) from input_string. </del>  Let parameters be an empty, ordered map.

Reviewer comments:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Revised text:
map of parameters. input_string is modified to remove the parsed value.  <ins> Let primary_item be the result of Parsing an item from Text (parse-item) from input_string. </ins> Let parameters be an empty, ordered map.
Original text:
Add key param_name with value param_value to parameters. <del> Return the tuple (primary_identifier, parameters). </del>  4.2.6.

Reviewer comments:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Revised text:
Add key param_name with value param_value to parameters.  <ins> Return the tuple (primary_item, parameters). </ins> 4.2.6.
Original text:
SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. <del> Reference: [FIPS-180-3], RFC4648, this document. </del>  Status: obsoleted

Reviewer comments:
fixes typo in reference
FYI, there is (at least) a 180-4 now.

Revised text:
SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459.  <ins> Reference: FIPS180-3, RFC4648, this document. </ins> Status: obsoleted
Original text:
1. Integrity protection for HTTP content is multi layered and is usually <del> achieved across the protocol stack: TCP checksums and TLS record to name but some. </del>  The HTTP protocol does not provide means to protect the various message parts.  Besides, it might be desirable to add additional

Reviewer comments:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Revised text:
1. Integrity protection for HTTP content is multi layered and is usually  <ins> achieved across the protocol stack: TCP checksums and TLS RFC2818 record to name but some. </ins> The HTTP protocol does not provide means to protect the various message parts.  Besides, it might be desirable to add additional
Original text:
This approach can be easily adapted to use-cases where the transferred data does require some sort of manipulation to be considered a representation or conveys a partial representation of a <del> resource (eg.  Range Requests). </del>  Changes are semantically compatible with existing implementations and better cover both the request and response cases.

Reviewer comments:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Revised text:
This approach can be easily adapted to use-cases where the transferred data does require some sort of manipulation to be considered a representation or conveys a partial representation of a  <ins> resource (eg.  Range Requests RFC7233). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.
Original text:
should decouple the checksum calculation: from the payload body - which may be altered by mechanism like <del> Range Requests or the method (eg.  HEAD); </del>  and from the message body - which depends on "Transfer-Encoding" and whatever tranformations the intermediaries may apply.

Reviewer comments:
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in

Revised text:
should decouple the checksum calculation: from the payload body - which may be altered by mechanism like  <ins> Range Requests RFC7233 or the method (eg.  HEAD); </ins> and from the message body - which depends on "Transfer-Encoding" and whatever tranformations the intermediaries may apply.
Original text:
Resource Digests for HTTP <del> draft-ietf-httpbis-digest-headers </del>  Abstract

Reviewer comments:
Adds -latest to docname
[x] WARNING: The Internet-Draft name 'draft-ietf-httpbis-digest-headers' should end with a two-digit sequence number or 'latest'. (at line 20)

Revised text:
Resource Digests for HTTP  <ins> draft-ietf-httpbis-digest-headers-latest </ins> Abstract
Original text:
A final (but significant) goal is to provide for ease of implementation, deployment and operation.  This mechanism is expected <del> to have a minimal impact upon performance, and a trivial </del>  administrative effort to configure. 1.2.

Reviewer comments:
consistent use of instead of "http" make S1.1, P3 a bit more readable

Revised text:
A final (but significant) goal is to provide for ease of implementation, deployment and operation.  This mechanism is expected  <ins> to have a minimal impact upon performance, and require a trivial </ins> administrative effort to configure. 1.2.
Original text:
additional response header fields to convey related values to aid client processing. <del> 2.2.1. </del>  <del> Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </del>  For example:

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
additional response header fields to convey related values to aid client processing.  <ins> 3. Servers can advertise support for Client Hints using the mechnisms described below. 3.1. </ins>  <ins> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure.  Its value MUST be an sh- list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:
Original text:
same-origin resource requests initiated by the page constructed from the response. <del> 2.2.2. </del>  Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable

Reviewer comments:
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!

Revised text:
same-origin resource requests initiated by the page constructed from the response.  <ins> 3.2. </ins> Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable