jiebi/TextFlow huggingface dataset:
Original text:
9.5.19.  The status code indicates that the server refuses to perform the request

Reviewer comments:
The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.

Revised text:
9.5.19. <ins> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a 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 contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. 9.5.20. </ins> The status code indicates that the server refuses to perform the request
Original text:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code)  426 Upgrade Required (status code) 4xx Client Error (status code class)

Reviewer comments:
The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.

Revised text:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 422 Unprocessable Entity (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)
Original text:
9.5.19.  The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a

Reviewer comments:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Revised text:
9.5.19. <ins> RFC2324 was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code.  In the intervening years, this status code has been widely implemented as an "Easter Egg", and therefore is effectively consumed by this use. Therefore, the 418 status code is reserved in the IANA HTTP Status Code registry.  This indicates that the status code cannot be assigned to other applications currently.  If future circumstances require its use (e.g., exhaustion of 4NN status codes), it can be re- assigned to another use. 9.5.20. </ins> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a
Original text:
contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. <del> 9.5.20. </del>  The

Reviewer comments:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Revised text:
contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.  <ins> 9.5.21. </ins> The
Original text:
status code values summarized in the table of overview.of.status.codes.  13.4. Please update the "Message Headers" registry of "Permanent Message

Reviewer comments:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Revised text:
status code values summarized in the table of overview.of.status.codes. <ins> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </ins> 13.4. Please update the "Message Headers" registry of "Permanent Message
Original text:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code)  422 Unprocessable Entity (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Reviewer comments:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Revised text:
415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 418 (Unused) (status code) </ins> 422 Unprocessable Entity (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)
Original text:
5.2.2.1. The "must-revalidate" response directive indicates that once it has <del> become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server. </del>  The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a

Reviewer comments:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Revised text:
5.2.2.1. The "must-revalidate" response directive indicates that once it has  <ins> become stale, the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. </ins> The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a
Original text:
The "no-cache" response directive indicates that the response MUST <del> NOT be used to satisfy a subsequent request without successful validation on the origin server.  This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </del>  If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request,

Reviewer comments:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Revised text:
The "no-cache" response directive indicates that the response MUST  <ins> NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </ins> If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request,
Original text:
5.2.2.3. The "no-store" response directive indicates that a cache MUST NOT <del> store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT </del>  store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as

Reviewer comments:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Revised text:
5.2.2.3. The "no-store" response directive indicates that a cache MUST NOT  <ins> store any part of either the immediate request or response, and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.  "MUST NOT </ins> store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as
Original text:
The request method is understood by the cache and defined as being cacheable, and  the response status code is understood by the cache, and the "no-store" cache directive (see header.cache-control) does not

Reviewer comments:
seems like it should be in messaging.
Part of it needs to be in messaging (how to do it per version), while a shorter description needs to be here just to point out that it is version dependent. The semantics don't make any sense otherwise.
Ack. Will take a stab at it.
The caching document should clarify that only final responses are cached.
Works for me.

Revised text:
The request method is understood by the cache and defined as being cacheable, and <ins> the response status code is final (see associating.response.to.request), and </ins> the response status code is understood by the cache, and the "no-store" cache directive (see header.cache-control) does not
Original text:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST: </del>  <del> delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, use other header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del>  4.

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a  <ins> cache MUST use the header fields provided in the new response, aside from </ins>  <ins> , to replace all instances of the corresponding header fields in the stored response. </ins> 4.
Original text:
interval since that time.  A typical setting of this fraction might be 10%. <del> When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a header field with a 113 warn-code (see warn.113) in the response if its current_age is more than 24 hours and such a warning is not already present. </del> 4.2.3. The

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
interval since that time.  A typical setting of this fraction might be 10%.  4.2.3. The
Original text:
forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). <del> A cache SHOULD generate a header field with the 110 warn-code (see warn.110) in stale responses.  Likewise, a cache SHOULD generate a 112 warn-code (see warn.112) in stale responses if the cache is disconnected. A cache SHOULD NOT generate a new header field when forwarding a response that does not have an header field, even if the response is already stale.  A cache need not validate a response that merely became stale in transit. </del> 4.3. When a cache has one or more stored responses for a requested URI,

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive).  4.3. When a cache has one or more stored responses for a requested URI,
Original text:
response also lacks a validator, then that stored response is identified for update. <del> For each stored response identified for update, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, </del>  <del> use other header fields provided in the response to replace all instances of the corresponding header fields in the stored response. </del>  4.3.5.

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
response also lacks a validator, then that stored response is identified for update.  <ins> For each stored response identified for update, the cache MUST use the header fields provided in the </ins>  <ins> response to replace all instances of the corresponding header fields in the stored response. </ins> 4.3.5.
Original text:
consider the stored response to be stale. If a cache updates a stored response with the metadata provided in a <del> HEAD response, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any </del>  <del> header fields in the stored response with warn-code 2xx; and, use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del>  4.4.

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
consider the stored response to be stale. If a cache updates a stored response with the metadata provided in a  <ins> HEAD response, the cache MUST use the header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the </ins>  <ins> header field. </ins> 4.4.
Original text:
8.3. <del> Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> with the registration procedure of warn.code.registry and the warn code values summarized in the table of header.warning. </del>  Index <del> 1 110 (warn-code) 111 (warn-code) 112 (warn-code) 113 (warn-code) 199 (warn-code) 2 214 (warn-code) 299 (warn-code) </del> A Age header field age

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
8.3.  <ins> Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> to the effect that Warning is obsoleted. </ins> Index  A Age header field age
Original text:
cache entry cache key <del> D Disconnected Operation (warn-text) </del> E Expires header field explicit expiration time

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
cache entry cache key  E Expires header field explicit expiration time