jiebi/TextFlow huggingface dataset:
Original text:
For example, <del> A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings.  Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings. </del> A server tests whether a content-coding for a given representation is acceptable using these rules:

Reviewer comments:
(alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.

Revised text:
For example,  A server tests whether a content-coding for a given representation is acceptable using these rules:
Original text:
would mean: "I prefer Danish, but will accept British English and other types of English". <del> A request without any Accept-Language header field implies that the user agent will accept any language in response.  If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a response.  However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example). </del> Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1).

Reviewer comments:
(alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.

Revised text:
would mean: "I prefer Danish, but will accept British English and other types of English".  Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1).
Original text:
A recipient MUST be able to parse and decode the chunked transfer coding.  7.1.1. The chunked encoding allows each chunk to include zero or more chunk

Reviewer comments:
This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.

Revised text:
A recipient MUST be able to parse and decode the chunked transfer coding. <ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.1.1. The chunked encoding allows each chunk to include zero or more chunk
Original text:
The following transfer coding names for compression are defined by the same algorithm as their corresponding content coding:  7.3. The "HTTP Transfer Coding Registry" defines the namespace for

Reviewer comments:
This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.

Revised text:
The following transfer coding names for compression are defined by the same algorithm as their corresponding content coding: <ins> The compression codings do not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.3. The "HTTP Transfer Coding Registry" defines the namespace for
Original text:
sending a payload body on a DELETE request might cause some existing implementations to reject the request. <del> Responses to the DELETE method are not cacheable.  If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </del>  7.3.6.

Reviewer comments:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Revised text:
sending a payload body on a DELETE request might cause some existing implementations to reject the request.  <ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </ins> 7.3.6.
Original text:
registries to indicate that HTTP header field registrations have moved, with an appropriate link. <del> After that is complete, please update the registry with the header field names listed in the table of field.names. </del>  13.5.

Reviewer comments:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Revised text:
registries to indicate that HTTP header field registrations have moved, with an appropriate link.  <ins> After that is complete, please update the new registry with the header field names listed in the table of field.names. Finally, please update the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to RFC2616 (for the definition of the header field) and RFC7231 (which removed the field definition from the updated specification). </ins> 13.5.
Original text:
Content-Language header field Content-Length header field Content-Location header field  Content-Range header field Content-Type header field cache

Reviewer comments:
I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.

Revised text:
Content-Language header field Content-Length header field Content-Location header field <ins> Content-MD5 header field </ins> Content-Range header field Content-Type header field cache
Original text:
A client that generates an OPTIONS request containing a payload body MUST send a valid <del> header field describing the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource. </del>  Responses to the OPTIONS method are not cacheable.

Reviewer comments:
() work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.

Revised text:
A client that generates an OPTIONS request containing a payload body MUST send a valid  <ins> header field describing the representation media type.  Note that this specification does not define any use for such a payload. </ins> Responses to the OPTIONS method are not cacheable.
Original text:
and for n >= 1 and m > 1: <del> For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: </del>  <del> Empty elements do not contribute to the count of elements present. </del> For example, given these ABNF productions: Then the following are valid values for example-list (not including

Reviewer comments:
() work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.

Revised text:
and for n >= 1 and m > 1:  <ins> Empty elements do not contribute to the count of elements present.  A recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of- service mechanism.  In other words, a recipient MUST accept lists that satisfy the following syntax: Note that because of the potential presence of empty list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements, and consequently all cases are mapped is if there was no cardinality specified. </ins>  For example, given these ABNF productions: Then the following are valid values for example-list (not including
Original text:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.04. </del>  1.

Reviewer comments:
NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?

Revised text:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>.  <ins> The changes in this draft are summarized in changes.since.05. </ins> 1.
Original text:
3.1. A response message is considered complete when all of the octets <del> indicated by the message framing (Messaging) are received prior to the connection being closed.  If the request method is GET, the response status code is </del>  , and the entire response header section has been received, a cache MAY store an incomplete response message body if the cache entry is

Reviewer comments:
NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?

Revised text:
3.1. A response message is considered complete when all of the octets  <ins> indicated by its framing are available.  Note that this includes a message that is ended by the connection's close (see Messaging). Although caches are encouraged to consider such a response incomplete when the connection termination was irregular, that is not always possible to detect; therefore, servers wishing to avoid caching of partial responses due to connection termination will need to use explicit framing. If the request method is GET, the response status code is </ins> , and the entire response header section has been received, a cache MAY store an incomplete response message body if the cache entry is
Original text:
the request will have the same intended effect, even if the original request succeeded, though the response might differ.  7.2.3. Request methods can be defined as "

Reviewer comments:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Revised text:
the request will have the same intended effect, even if the original request succeeded, though the response might differ. <ins> A user agent MUST NOT automatically retry a request with a non- idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  For example, a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that request automatically.  Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed. A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry. </ins> 7.2.3. Request methods can be defined as "
Original text:
9.5.20. <del> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a </del>  <del> status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body </del>  contains well-formed (i.e., syntactically correct), but semantically <del> erroneous, XML instructions. </del>  9.5.21.

Reviewer comments:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Revised text:
9.5.20.  <ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a </ins>  <ins> status code is inappropriate), and the syntax of the request payload is correct, but was unable to process the contained instructions. For example, this status code can be sent if an XML request payload </ins> contains well-formed (i.e., syntactically correct), but semantically  <ins> erroneous XML instructions. </ins> 9.5.21.
Original text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <del> 422 Unprocessable Entity (status code) </del>  426 Upgrade Required (status code) 4xx Client Error (status code class)

Reviewer comments:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Revised text:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code)  <ins> 422 Unprocessable Payload (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)