jiebi/TextFlow huggingface dataset:
Original text:
is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> Responses (both </del>  <del> and </del>  <del> ) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del>  7.6.

Reviewer comments:
though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.

Revised text:
is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier.  <ins> All responses, regardless of the status code (including </ins>  <ins> responses) can be sent at any time after a request is received, even if the request is not yet complete.  A response can complete before its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins>  <ins> A client that receives a response while the associated request is still being sent SHOULD continue sending that request, unless it receives an explicit indication to the contrary (see, e.g., persistent.failures and RFC7540). </ins> 7.6.
Original text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del>  10.1.3.

Reviewer comments:
though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.

Revised text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or  <ins> authentication. </ins> 10.1.3.
Original text:
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying <del> header fields.  If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in safe.methods, the method semantics take precedence. </del>  HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and

Reviewer comments:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Revised text:
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying  <ins> header fields.  A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request.  For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see safe.methods). </ins> HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and
Original text:
is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> Responses (both </del>  <del> and </del>  <del> ) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </del>  7.6.

Reviewer comments:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Revised text:
is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier.  <ins> All responses, regardless of the status code (including </ins>  <ins> responses) can be sent at any time after a request is received, even if the request is not yet complete.  A response can complete before its corresponding request is complete.  Likewise, clients are not expected to wait any specific amount of time for a response.  Clients (including intermediaries) might abandon a request if the response is not forthcoming within a reasonable period of time. </ins>  <ins> A client that receives a response while the associated request is still being sent SHOULD continue sending that request, unless it receives an explicit indication to the contrary (see, e.g., persistent.failures and RFC7540). </ins> 7.6.
Original text:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Reviewer comments:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Revised text:
8.3.3.  MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Original text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del>  10.1.3.

Reviewer comments:
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.

Revised text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or  <ins> authentication. </ins> 10.1.3.
Original text:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Reviewer comments:
... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.

Revised text:
8.3.3.  MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Original text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del>  10.1.3.

Reviewer comments:
... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.

Revised text:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or  <ins> authentication. </ins> 10.1.3.
Original text:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Reviewer comments:
implies a requirement: I would have said instead that HTTP itself doesn't care whether content adheres to this stricture, though some implementations could (or MAY) normalize line endings before sending or after receiving content that uses a media type.
Maybe we can improve the spec by just killing the whole subsection? It refers to the canonical form in MIME, then say we don't neef that, and then makes recommendations for text/* that AFAIU everbody ignores.
This was a huge deal back in 1995-96 and was necessary to bless deployed practice of sending native line endings and expecting the user agents to process them. I guess we can ignore that now? Don't be surprised if JK brings this up in IESG last call.Not seeing anything here worth saving.

Revised text:
8.3.3.  MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and
Original text:
A recipient MUST be able to parse and decode the chunked transfer coding. <del> Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. </del>  The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error.

Reviewer comments:
Note that if we say it has serious security hazards and we don't mention that in Security Considerations, someone might complain.
PTAL
The text says I'd want to add: "Implementations must be careful about accurately parsing large values or rejecting the messages, as failure to accurately represent the advertised value due to overflows or loss of precision may have serious security consequences." I think it is important to remind, because implementations seem to have progressively shifted towards 64 bit repressentations since 7230, 32-bit ones are still much present, and the risk of desynchronization by advertising more than 4GB is high. By the way, some languages do no provide more than 52 bits of accuracy because they use floats to represent any number... The risk remains low (1 injected byte every 4 PB) but its worth asking to be careful.
Tweaked proposal:
WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"
I think if we say something about that, we should align it with the language for Content-Length:
OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say . We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!

Revised text:
A recipient MUST be able to parse and decode the chunked transfer coding.  <ins> HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response.  Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation.  Therefore, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation. </ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error.