jiebi/TextFlow huggingface dataset:
Original text:
distinguishes it from the Name Length field, which cannot contain a value of 0. <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> Indeterminate-length messages can be truncated in a similar way as known-length messages; see padding.

Reviewer comments:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Revised text:
distinguishes it from the Name Length field, which cannot contain a value of 0.  Indeterminate-length messages can be truncated in a similar way as known-length messages; see padding.
Original text:
3.5. The control data for a response message consists of the status code. <del> The status code is encoded as a variable length integer, not a </del>  length-prefixed decimal string. The format of final response control data is shown in format-

Reviewer comments:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Revised text:
3.5. The control data for a response message consists of the status code.  <ins> The status code (HTTP) is encoded as a variable length integer, not a </ins> length-prefixed decimal string. The format of final response control data is shown in format-
Original text:
3.5.1. <del> Responses that include information status codes (see HTTP) are </del>  encoded by repeating the response control data and associated header section until the final status code is encoded.

Reviewer comments:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Revised text:
3.5.1.  <ins> Responses that include informational status codes (see HTTP) are </ins> encoded by repeating the response control data and associated header section until the final status code is encoded.
Original text:
format-informational. A response message can include any number of informational responses <del> that precede a final status code.  These convey an information status code and a header block. </del>  If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is

Reviewer comments:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Revised text:
format-informational. A response message can include any number of informational responses  <ins> that precede a final status code.  These convey an informational status code and a header block. </ins> If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is
Original text:
Header and trailer sections consist of zero or more field lines; see HTTP.  The format of a field section depends on whether the message <del> is known- or intermediate-length. </del>  Each field line includes a name and a value.  Both the name and value are length-prefixed sequences of bytes.  The field name length is at

Reviewer comments:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Revised text:
Header and trailer sections consist of zero or more field lines; see HTTP.  The format of a field section depends on whether the message  <ins> is known- or indeterminate-length. </ins> Each field line includes a name and a value.  Both the name and value are length-prefixed sequences of bytes.  The field name length is at
Original text:
Responses that include informational status codes (see HTTP) are encoded by repeating the response control data and associated header <del> section until the final status code is encoded. </del>  The format of the informational response control data is shown in format-informational.

Reviewer comments:
Just a little more explanation. And .
Comment by NAME : I see that the talks about "final status code": and that explains why you called it "final" in , but I think you need to define why "final" is used in the "final response control data" when it first appear (so in ), or you can remove "final" in 3.5 and explain that only in 3.5.1.

Revised text:
Responses that include informational status codes (see HTTP) are encoded by repeating the response control data and associated header  <ins> section until a final response control data is encoded.  The status code distinguishes between informational and final responses. </ins> The format of the informational response control data is shown in format-informational.
Original text:
3.1. <del> A message that has a known length at the time of construction uses the format shown in format-known-length. </del>  <del> That is, a known-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section with a length prefix, binary content with a length prefix, and a trailer section with a length prefix. </del>  <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. </del>  For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is

Reviewer comments:
Arguably a technical change, though as it is in a picture, so I want to highlight it. This is on top of , so just look at 5468983321b104de62b1aae8df8963ad1abd5fa9 if you want to see the "technical" change.

Revised text:
3.1.  <ins> A request or response that has a known length at the time of construction uses the format shown in format-known-length. </ins>  <ins> A known-length request consists of a framing indicator (framing), request control data (request-control), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding. </ins>  <ins> A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) followed by response control data (response-control). </ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is
Original text:
3.2. <del> A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: </del>  <del> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del>  <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del>  The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be

Reviewer comments:
Arguably a technical change, though as it is in a picture, so I want to highlight it. This is on top of , so just look at 5468983321b104de62b1aae8df8963ad1abd5fa9 if you want to see the "technical" change.

Revised text:
3.2.  <ins> A request or response that is constructed without encoding a known length for each section uses the format shown in format- indeterminate-length: </ins>  <ins> An indeterminate-length request consists of a framing indicator (framing), request control data (request-control), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding. </ins>  <ins> An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) and response control data (response-control). </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be
Original text:
contains a digest value computed by applying a hashing algorithm to selected representation data (SEMANTICS).  Basing "Repr-Digest" on the selected representation makes it straightforward to apply it to <del> use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </del>  "Content-Digest" and "Repr-Digest" support hashing algorithm agility. The "Want-Content-Digest" and "Want-Repr-Digest" fields allow endpoints to express interest in "Content-Digest" and "Repr-Digest" <del> respectively, and preference of algorithms in either. </del>  "Content-Digest" and "Repr-Digest" are collectively termed Integrity fields.  "Want-Content-Digest" and "Want-Repr-Digest" are

Reviewer comments:
I had to read this several times to understand what parts of the sentence were replicated into the "or" part of the statement. Duplicating some words makes it a tiny bit more comprehensible, I think.
LGTM

Revised text:
contains a digest value computed by applying a hashing algorithm to selected representation data (SEMANTICS).  Basing "Repr-Digest" on the selected representation makes it straightforward to apply it to  <ins> use-cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </ins> "Content-Digest" and "Repr-Digest" support hashing algorithm agility. The "Want-Content-Digest" and "Want-Repr-Digest" fields allow endpoints to express interest in "Content-Digest" and "Repr-Digest"  <ins> respectively, and to express algorithm preferences in either. </ins> "Content-Digest" and "Repr-Digest" are collectively termed Integrity fields.  "Want-Content-Digest" and "Want-Repr-Digest" are
Original text:
framing, which describes whether the message is a request or response and how subsequent sections are formatted; see framing. <del> For a response, any number of interim responses, each consisting of an informational status code and header section. </del>  Control data.  For a request, this contains the request method and target.  For a response, this contains the status code.

Reviewer comments:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Revised text:
framing, which describes whether the message is a request or response and how subsequent sections are formatted; see framing.  <ins> For a response, any number of informational responses, each consisting of an informational status code and header section. </ins> Control data.  For a request, this contains the request method and target.  For a response, this contains the status code.
Original text:
for the semantics of repeated field names and rules for combining values.  Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields <del> allows a binary message to capture the content of a messages that are exchanged in a protocol context. </del>  <del> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </del>  3.7.

Reviewer comments:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Revised text:
for the semantics of repeated field names and rules for combining values. <ins> Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2). Field lines containing pseudo-fields MUST precede other field lines. A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields  <ins> allows a binary message to capture messages that are exchanged in a protocol context. </ins>  <ins> Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </ins> 3.7.
Original text:
4. This document describes a number of ways that a message can be <del> invalid.  Invalid messages MUST NOT be processed except to log an error and produce an error response. </del>  The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error

Reviewer comments:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Revised text:
4. This document describes a number of ways that a message can be  <ins> invalid.  Invalid messages MUST NOT be processed further except to log an error and produce an error response. </ins> The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error
Original text:
This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in ex-bink- <del> request.  ex-bink-request view includes some of the text alongside to show that most of the content is not modified. </del>  This example shows that the Host header field is not replicated in <del> the :authority field, as is required for ensuring that the request is reproduced accurately; see H2. </del>  The same message can be truncated with no effect on interpretation. In this case, the last two bytes - corresponding to content and a

Reviewer comments:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Revised text:
This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in ex-bink-  <ins> request.  ex-bink-request includes text alongside to show that most of the content is not modified. </ins> This example shows that the Host header field is not replicated in  <ins> the ":authority" field, as is required for ensuring that the request is reproduced accurately; see H2. </ins> The same message can be truncated with no effect on interpretation. In this case, the last two bytes - corresponding to content and a
Original text:
Some of these features are also absent in HTTP/2 and HTTP/3. Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control <del> data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del>  Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no

Reviewer comments:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Revised text:
Some of these features are also absent in HTTP/2 and HTTP/3. Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control  <ins> data rather than using pseudo-fields. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no