jiebi/TextFlow huggingface dataset:
Original text:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </del>  4.

Reviewer comments:
NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!

Revised text:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a  <ins> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </ins> 4.
Original text:
5. This document registers a new setting in the "HTTP/3 Settings" <del> registry (HTTP3). </del> 

Reviewer comments:
NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!

Revised text:
5. This document registers a new setting in the "HTTP/3 Settings"  <ins> registry (HTTP/3). </ins>
Original text:
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP/2 that is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del>  2.

Reviewer comments:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Revised text:
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension  <ins> to HTTP/2 HTTP2 that is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.
Original text:
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined in RFC8441.  HTTP/3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del>  SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Reviewer comments:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Revised text:
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical  <ins> to those in HTTP/2 as defined in RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.
Original text:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </del>  4.

Reviewer comments:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Revised text:
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a  <ins> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </ins> 4.
Original text:
5. This document registers a new setting in the "HTTP/3 Settings" <del> registry (HTTP/3). </del> 

Reviewer comments:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Revised text:
5. This document registers a new setting in the "HTTP/3 Settings"  <ins> registry (HTTP3). </ins>
Original text:
Some of these features are also absent in HTTP/2 and HTTP/3. <del> Unlike HTTP/2 and HTTP/3, this format uses a a fixed format for control 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:
Typi fix
I had to read that three times to spot your change. Something about that text blinded me to that.

Revised text:
Some of these features are also absent in HTTP/2 and HTTP/3.  <ins> Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control 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. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no
Original text:
For more advanced use-cases, the "Repr-Digest" request and response header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to <del> "selected representation data" (SEMANTICS).  Basing "Repr-Digest" on </del>  the selected representation makes it straightforward to apply it to use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
For more advanced use-cases, the "Repr-Digest" request and response header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to  <ins> selected representation data (SEMANTICS).  Basing "Repr-Digest" on </ins> the selected representation makes it straightforward to apply it to use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial
Original text:
integrity.  It also coined the term "instance" and "instance manipulation" in order to explain concepts that are now more universally defined, and implemented, as HTTP semantics such as <del> "selected representation data" (SEMANTICS). </del>  Experience has shown that implementations of RFC3230 have interpreted the meaning of "instance" inconsistently, leading to interoperability

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
integrity.  It also coined the term "instance" and "instance manipulation" in order to explain concepts that are now more universally defined, and implemented, as HTTP semantics such as  <ins> selected representation data (SEMANTICS). </ins> Experience has shown that implementations of RFC3230 have interpreted the meaning of "instance" inconsistently, leading to interoperability
Original text:
The "Repr-Digest" HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm <del> applied to the entire "selected representation data" (see SEMANTICS). </del>  Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
The "Repr-Digest" HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm  <ins> applied to the entire selected representation data (see SEMANTICS). </ins> Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests
Original text:
representation concepts, several examples are provided in resource- representation. <del> When a message has no "representation data" it is still possible to assert that no "representation data" was sent by computing the digest </del>  on an empty string (see usage-in-signatures). "Repr-Digest" is a "Dictionary" (see STRUCTURED-FIELDS) where each:

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
representation concepts, several examples are provided in resource- representation.  <ins> When a message has no representation data it is still possible to assert that no representation data was sent by computing the digest </ins> on an empty string (see usage-in-signatures). "Repr-Digest" is a "Dictionary" (see STRUCTURED-FIELDS) where each:
Original text:
6.1. This document specifies a data integrity mechanism that protects HTTP <del> "representation data" or content, but not HTTP header and trailer </del>  fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
6.1. This document specifies a data integrity mechanism that protects HTTP  <ins> representation data or content, but not HTTP header and trailer </ins> fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against
Original text:
6.2. <del> Integrity fields can help detect "representation data" or content </del>  modification due to implementation errors, undesired "transforming proxies" (see SEMANTICS) or other actions as the data passes across multiple hops or system boundaries.  Even a simple mechanism for end- <del> to-end "representation data" integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </del>  Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could

Reviewer comments:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Revised text:
6.2.  <ins> Integrity fields can help detect representation data or content </ins> modification due to implementation errors, undesired "transforming proxies" (see SEMANTICS) or other actions as the data passes across multiple hops or system boundaries.  Even a simple mechanism for end-  <ins> to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could
Original text:
a known-length encoding includes length prefixes for all major message components; and <del> an indefinite-length encoding enables efficient generation of </del>  messages where lengths are not known when encoding starts. This format is designed to convey the semantics of valid HTTP

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:
a known-length encoding includes length prefixes for all major message components; and  <ins> an indeterminate-length encoding enables efficient generation of </ins> messages where lengths are not known when encoding starts. This format is designed to convey the semantics of valid HTTP
Original text:
content with a length prefix, and a trailer section with a length prefix. <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 the number of bytes in the field section or content. </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.  Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.

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:
content with a length prefix, and a trailer section with a length prefix.  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. <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 the number of bytes in the field section or content, not including the length field itself. </ins> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.
Original text:
A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: <del> That is, an indeterminate length 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>  The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be

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:
A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length:  <ins> 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. 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. </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be