jiebi/TextFlow huggingface dataset:
Original text:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as <del> HTTP/0.9. </del>  HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as  <ins> HTTP/0.9 (see HTTP09). </ins> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")
Original text:
its payload, the target resource, or the connection.  They are called "HTTP fields" or just " <del> ". </del>  Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
its payload, the target resource, or the connection.  They are called "HTTP fields" or just "  <ins> ".  Fields occur in groups called " " or just "sections". </ins> Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located
Original text:
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma and </del>  (optional whitespace).  For consistency, use comma SP.

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.  <ins> A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma and </ins> (optional whitespace).  For consistency, use comma SP.
Original text:
Obsolete formats: <del> HTTP-date is case sensitive.  A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.  The semantics of </del>  ,

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
Obsolete formats:  <ins> HTTP-date is case sensitive.  Note that Caching relaxes this for cache recipients. A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.  The semantics of </ins> ,
Original text:
After that is complete, please update the new registry with the field names listed in the following table. <del> Furthermore, the field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </del>  header field (field.vary).

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
After that is complete, please update the new registry with the field names listed in the following table.  <ins> The field name "*" is reserved, since using that name as an HTTP header field might conflict with its special semantics in the </ins> header field (field.vary).
Original text:
4xx Client Error 5xx Server Error safe  secured selected representation sender

Reviewer comments:
The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.

Revised text:
4xx Client Error 5xx Server Error safe <ins> section </ins> secured selected representation sender
Original text:
Also, note that unsafe requests might invalidate already-stored responses; see invalidation.  When more than one suitable response is stored, a cache MUST use the most recent one (as determined by the

Reviewer comments:
We should really mention this, as it's common and can cause misunderstanding. I also am likely to need to reference it in .
Maybe add a minimal explanation of "collapse"?

Revised text:
Also, note that unsafe requests might invalidate already-stored responses; see invalidation. <ins> A response that is stored or storable can be used to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question.  This enables caches to "collapse" multiple incoming requests into a single forward request upon a cache miss, thereby reducing load on the origin server and network.  However, note that if the response returned is not able to be used for some or all of the collapsed requests, additional latency might be introduced, because they will need to be forwarded to be satisfied. </ins> When more than one suitable response is stored, a cache MUST use the most recent one (as determined by the
Original text:
When there is more than one value present for a given directive (e.g., two <del> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid.  Caches are encouraged to consider responses that have invalid freshness information to be stale. </del>  4.2.2.

Reviewer comments:
says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.

Revised text:
When there is more than one value present for a given directive (e.g., two  <ins> header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used, or the response should be considered stale.  If directives conflict (e.g., both max-age and no- cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale. </ins> 4.2.2.
Original text:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del>  The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Reviewer comments:
says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.

Revised text:
age.calculations. The Age field value is a non-negative integer, representing time in  <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Original text:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del>  The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Reviewer comments:
NAME It already is, this just changes how it's done.
My seem to indicate we might want to reconsider how . Of implementations that honour (two don't): none will consider invalid none will consider on two separate field lines invalid none will consider a duplicated value on two lines to make the header invalid if there are two header lines, all will consider only the first (and one, Safari, appears to use the min of them) none considers a non-numeric value to be invalid only Fastly and Firefox consider a non-negative integer to be invalid ... where invalid currently is required to be considered stale.

Revised text:
age.calculations. The Age field value is a non-negative integer, representing time in  <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Original text:
15.3.  15.3.1. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines

Reviewer comments:
I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .

Revised text:
15.3. <ins> HTTP's most widely used extensibility point is the definition of new header and trailer fields. New fields can be defined such that, when they are understood by a recipient, they override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. However, defining a field doesn't guarantee its deployment or recognition by recipients.  Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized.  In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type.  Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI RFC8615 if such inspection is defined along with the field being introduced. </ins> 15.3.1. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
Original text:
15.3.2. <del> There is no limit on the introduction of new field names, each presumably defining new semantics. New fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses. </del> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on

Reviewer comments:
I believe that we said this could be merged when Julian's issue was addressed, which Roy's suggestion did, so merging.
Some guidance about how and if new preconditions can be defined would be helpful. See .

Revised text:
15.3.2.  Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on
Original text:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as <del> HTTP/0.9. </del>  HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")

Reviewer comments:
NAME - is Oct 1999 correct? (taken from Last-Modified)
Last edit is 1999 but was just a markup fix, original document is dated 1996-10-03. HTH,
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.

Revised text:
mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname.  This original protocol is now referred to as  <ins> HTTP/0.9 (see HTTP09). </ins> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version")
Original text:
5.2. <del> One of the functions of message framing is to assure that messages are . A message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the transport connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport- level error indicates that it is not complete. </del>  5.3.

Reviewer comments:
When I was restructuring Semantics, the paragraphs for defining when a message is complete stuck out like a sore thumb. I moved them to their own section and added a comment for later definition. This issue tracks that definition (editorial).

Revised text:
5.2.  <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </ins> 5.3.
Original text:
class of status code indicates an interim response for communicating connection status or request progress prior to completing the <del> requested action and sending a final response.  1xx responses are terminated by the end of the header section.  Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client. </del>  A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one.  A

Reviewer comments:
We need to discuss this; prohibition at least semantically, and probably also strongly urge against accepting on the wire for security reasons (although somewhat version-specific).
Discussed; just need to align 1xx language with others.

Revised text:
class of status code indicates an interim response for communicating connection status or request progress prior to completing the  <ins> requested action and sending a final response.  Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client. A 1xx response is terminated by the end of the header section because it cannot contain a message body or trailers. </ins> A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one.  A
Original text:
17.4.  Please create a new registry as outlined in field-name.registry. After creating the registry, all entries in the Permanent and

Reviewer comments:
IIUC httpbis-semantics changes the field name registry, thus updating BCP 90 / RFC3684. Is that correct? Should httpbis-semantics mention that? NAME
"obsoletes": no, because BCP 90 is also for email. "updates": yes, I think so. NAME
Hm; I suppose so, given that it's taking some of 3684's turf away.
Now does that make SEMANTICS part of BCP90?
I'm inclined to say no -- it modifies the scope of BCP90 to exclude HTTP header fields. Worth discussing more broadly, though.

Revised text:
17.4. <ins> This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864. It defines both a new registration procedure and moves HTTP field definitions into a separate registry. </ins> Please create a new registry as outlined in field-name.registry. After creating the registry, all entries in the Permanent and