jiebi/TextFlow huggingface dataset:
Original text:
5.2. <del> Historically, HTTP field line values could be extended over multiple </del>  lines by preceding each extra line with at least one space or horizontal tab (obs-fold).  This specification deprecates such line folding except within the message/http media type

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
5.2.  <ins> Historically, HTTP/1.x field values could be extended over multiple </ins> lines by preceding each extra line with at least one space or horizontal tab (obs-fold).  This specification deprecates such line folding except within the message/http media type
Original text:
The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and <del> encodings. </del>  10.2.

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and  <ins> encodings.  Because of the line length limitations, field values within message/http are allowed to use line folding ( ), as described in line.folding, to convey the field value over multiple lines.  A recipient of message/http data MUST replace any obsolete line folding with one or more SP characters when the message is consumed. </ins> 10.2.
Original text:
forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string. <del> Historically, HTTP field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab ( ).  This document assumes that any such obsolete line folding has been removed prior to interpreting the field value (e.g., as described in line.folding). </del> 5.6. 5.6.1.

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string.  5.6. 5.6.1.
Original text:
8.8. <del> Validator fields convey metadata about the </del>  <del> (representations).  In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the status code </del>  semantics, the for a given response is not necessarily the same as the

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
8.8.  <ins> Resource metadata is referred to as a if it can be used within a precondition (preconditions) to make a conditional request (conditional.requests).  Validator fields convey a current validator for the (representations). </ins>  <ins> In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the method and status code </ins> semantics, the for a given response is not necessarily the same as the
Original text:
For example, an ETag field in a response communicates the entity-tag of the newly created resource's <del> representation, so that it can be used in later conditional requests to prevent the "lost update" problem (preconditions). </del>  This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
For example, an ETag field in a response communicates the entity-tag of the newly created resource's  <ins> representation, so that the entity-tag can be used as a validator in later conditional requests to prevent the "lost update" problem. </ins> This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:
Original text:
(field.etag).  Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning WEBDAV, that are beyond the scope of this <del> specification.  A resource metadata value is referred to as a when it is used within a precondition. </del>  8.8.1.

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
(field.etag).  Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning WEBDAV, that are beyond the scope of this  <ins> specification. </ins> 8.8.1.
Original text:
>> Response: <del> 8.8.4. In responses to GET or HEAD, an origin server: In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a value in successful responses to a retrieval request. A client: </del> 9. 9.1.

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
>> Response:  9. 9.1.
Original text:
indicated by the method definition or explicit cache controls (see heuristic.freshness).  15.3.2. The

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
indicated by the method definition or explicit cache controls (see heuristic.freshness). <ins> In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (response.validator) for the , with both a strong entity-tag and a date being preferred. In 200 responses to state-changing methods, any validator fields (response.validator) sent in the response convey the current validators for the new representation formed as a result of successfully applying the request semantics.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.2. The
Original text:
header field is received, by the target URI. The 201 response content typically describes and links to the <del> resource(s) created.  See response.validator for a discussion of the meaning and purpose of validator fields, such as and , in a 201 response. </del>  15.3.3.

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
header field is received, by the target URI. The 201 response content typically describes and links to the  <ins> resource(s) created.  Any validator fields (response.validator) sent in the response convey the current validators for a new representation created by the request.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.3.
Original text:
deliberately crafted to bypass security filters along the request chain. <del> A client MUST send a Host header field in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri).  If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </del>  A server MUST respond with a

Reviewer comments:
Reviewer: Marco Tiloca Review result: Ready with Nits Thanks for this document! I have found it very well written and I believe it's basically ready. Please, see below some minor comments and nits. Best, /Marco [X] [Section 1.2] As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP]. Editors: URL [X] [Section 3] "HTTP does not place a predefined limit on the length of a request-line, as described in Section 2 of [HTTP]" This can better point to Section 2.3 of [HTTP]. Editors: URL [X] [Section 3.2] "A client MUST send a Host header field in all HTTP/1.1 request messages." This sentence can be expanded to point to Section 7.2 of [HTTP]. "... excluding any userinfo subcomponent and its "NAME delimiter ..." This should point to Section 4.2.4 of [HTTP]. Editors: URL [X] [Section 3.3] "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client." Is "client" actually the intended word here? Or is it about using redirection to explain the client how to obtain something else (e.g. a proper authority component for a follow-up request) ? Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995. [X] [Section 7.1.2] I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences Editors: [X] [Section 9.8] "When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received ..." Shouldn't this be about received responses? Or does it refer to the completion of the exchanges started by the mentioned requests? Editors: yes, it's about the completion of the exchanges. [X] [Appendix A] The first paragraph can better point to Section 5.6.1 of [HTTP]. Editors: URL The reference for "absolute-path" should be Section 4.1 of [HTTP]. Editors: URL
Long indeed. NAME - do you want to give that a try?

Revised text:
deliberately crafted to bypass security filters along the request chain.  <ins> A client MUST send a header field (field.host) in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (http.uri). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. </ins> A server MUST respond with a
Original text:
information in multipart.byteranges for the media type "multipart/ byteranges".  18.9. Please update the "Service Name and Transport Protocol Port Number"

Reviewer comments:
The text in the document says: The Media Type Designated Experts' suggested to make that stronger, and have the following note on the : Let's agree on either "discouraged" or "prohibited", and align the text in the document and in the IANA registry note.
I believe what the IANA registry says is good, so what's left to do is to align our spec text with that. My understanding is that no new text in the IANA Considerations is needed, as the change to the registry already happened.
If we agree to add the reference to this RFC in the IANA note, once the RFC is published, I can ask IANA to do that.
Good point. We could add that to the IANA Considerations. Should I?
I think that would make sense. Let's hear from others.

Revised text:
information in multipart.byteranges for the media type "multipart/ byteranges". <ins> Furthermore please update the registry note about "q" parameters with a link to field.accept of this document. </ins> 18.9. Please update the "Service Name and Transport Protocol Port Number"
Original text:
9.8. <del> TLS provides a facility for secure connection closure through an exchange of closure alerts prior to closing a connection TLS13.  When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </del>  When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message

Reviewer comments:
Inspired by my ballot comments ( ) I started trying to write something about how it's required to send "close_notify" in normal connection shutdown, but didn't like how that worked, and ended up here. I am not sure if I regressed in some other axes while improving on this one, though.

Revised text:
9.8.  <ins> TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see TLS13. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </ins> When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message