jiebi/TextFlow huggingface dataset:
Original text:
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive). <del> A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). </del>  4.3.

Reviewer comments:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Revised text:
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive).  <ins> A cache MUST NOT send stale responses unless it is disconnected or doing so is explicitly allowed (e.g., by the max-stale request directive; see cache-request-directive). </ins> 4.3.
Original text:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a <del> cache cannot reach the origin server for any reason, it MUST generate a </del>  response.

Reviewer comments:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Revised text:
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a  <ins> cache is disconnected, it MUST generate a </ins> response.
Original text:
12.1. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the two tables of </del>  header.fields. 12.2.

Reviewer comments:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Revised text:
12.1.  <ins> Please update the "Hypertext Transfer Protocol (HTTP) Header Field Registry" registry at <https://www.iana.org/assignments/http-headers> with the header field names listed in the two tables of </ins> header.fields. 12.2.
Original text:
4.1.1. <del> HTTP header fields are registered within the "Message Headers" registry located at <https://www.iana.org/assignments/message- headers>, as defined by BCP90, with the protocol "http". </del>  4.1.2.

Reviewer comments:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Revised text:
4.1.1.  <ins> The "Hypertext Transfer Protocol (HTTP) Header Field Registry" defines the namespace for HTTP header field names Any party can request registration of a HTTP header field.  See considerations.for.new.header.fields for considerations to take into account when creating a new HTTP header field. The "HTTP Header Field Name" registry is located at "https://www.iana.org/assignments/http-headers/".  Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Header field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Header fields with the status 'permanent' are Specification Required (using terminology from RFC8126). Registration requests consist of at least the following information: The Expert(s) can define additional fields to be collected in the registry, in consultation with the community. Standards-defined names have a status of "permanent".  Other names can also be registered as permanent, if the Expert(s) find that they are in use, in consultation with the community.  Other names should be registered as "provisional". Provisional entries can be removed by the Expert(s) if -- in consultation with the community -- the Expert(s) find that they are not in use.  The Experts can change a provisional entry's status to permanent at any time. Note that names can be registered by third parties (including the Expert(s)), if the Expert(s) determines that an unregistered name is widely deployed and not likely to be registered in a timely manner otherwise. </ins> 4.1.2.
Original text:
requiring prior update of deployed intermediaries. All defined header fields ought to be registered with IANA in the <del> "Message Headers" registry. </del>  4.1.3.

Reviewer comments:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Revised text:
requiring prior update of deployed intermediaries. All defined header fields ought to be registered with IANA in the  <ins> "HTTP Header Field Name" registry. </ins> 4.1.3.
Original text:
13.4. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the table of field.names. </del>  13.5.

Reviewer comments:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Revised text:
13.4.  <ins> Please create a new registry as outlined in field.name.registry. After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to be moved to it, with the following changes applied: Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP header field registrations have moved, with an appropriate link. After that is complete, please update the registry with the header field names listed in the table of field.names. </ins> 13.5.
Original text:
8.1. <del> Please update the "Message Headers" registry of "Permanent Message Header Field Names" at <https://www.iana.org/assignments/message- headers> with the header field names listed in the table of </del>  header.field.definitions. 8.2.

Reviewer comments:
For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.

Revised text:
8.1.  <ins> Please update the "Hypertext Transfer Protocol (HTTP) Header Field Registry" registry at <https://www.iana.org/assignments/http-headers> with the header field names listed in the two tables of </ins> header.field.definitions. 8.2.
Original text:
) response.  9.4. HTTP/1.1 defaults to the use of "

Reviewer comments:
I also suggest closing here : the main reason for getting data without a request is an error reported by the server before closing (e.g. 408). Another reason may be a server implementation issue (extra CRLF, inconsistent multiple content-length, inconsistent content-length+transfer-encoding, user-fed incorrect error message). In all these cases the message delimitation is wrong and unrecoverable. Thus the client trying to "fix" it will in the best case be useless (close following), and in the worst case have nasty side effects. In haproxy the only case we try to address is the extra CRLF that a few old servers send slightly after data. If extra bytes are sent immediately after data, we close. If the extra CRLF happens slightly later, we find it while parsing the next response and the CRLF is silently skipped.
Everyone OK with this now?
Well, like Roy, I'd even prefer a MUST close, but I can live with a SHOULD.
It doesn't seem to account for the extra CRLF case. Maybe just add "... unless the data is limited to CRLF"?
CR and CRLF?
I was thinking the same but hesitating. BTW NAME it would be LF and CRLF. But quite frankly we could stick to CRLF only since it's the only known bogus pattern widely deployed in field.
updated.

Revised text:
) response. <ins> If an HTTP/1.1 client receives data on a connection that doesn't have any outstanding requests, it MUST NOT consider them to be a response to a not-yet-issued request; it SHOULD close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded, as per message.parsing). </ins> 9.4. HTTP/1.1 defaults to the use of "
Original text:
1.2. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del>  collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation.

Reviewer comments:
Also: change scripts that BAP is invoked with correct options. Note: I did not use "%i" for case-insensitive strings as this is the default anyway. If there is confusion about how a certain protocol element is matched, we should re-state that IMHO in the prose. The collected ABNF uses non-extended ABNF syntax. If this is a problem I'll need to do a bit more work on the tooling.
Should we just adopt wherever we use a string?
Yes, I think that's what the IESG wants us to do. (We were directed to use it in alt-svc)
I've started a branch (mnot-133). Question: do we want to convert things like this: into: ? We do that a fair amount for case-sensitive strings.
Yes. Let me take care of this.
+1
OK. I'll leave my branch there if you want to start with it; otherwise feel free to delete it.
FWIW, I'd prefer to do this only in the places where the string actually is case-sensitive.
I guess I forgot to close the ticket.
Looks good to me. I checked and we also say that they're case-sensitive in the accompanying prose for each instance (although for weak ETags, it's a bit far away).

Revised text:
1.2. This specification uses the Augmented Backus-Naur Form (ABNF)  <ins> notation of RFC5234, extended with the notation for case-sensitivity in strings defined in RFC7405. It also uses a list extension, defined in abnf.extension, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </ins> collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation.
Original text:
representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol.  8.4.1. Many of the request header fields for

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:
representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol. <ins> For each of these header fields, a request that does not contain it implies that the user agent has no preference on that axis of negotiation.  If the header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field.  This does not imply, however, that the client will be able to use the representation. Sending these header fields makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (fingerprinting). Each of these header fields defines a wildcard value (often, "*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. In practice, using wildcards in content negotiation has limited practical value, because it is seldom useful to say, for example, "I prefer image/* more or less than (some other specific value)". Clients can explicitly request a response if a more preferred format is not available by sending Accept: */*;q=0, but they still need to be able to handle a different response, since the server is allowed to ignore their preference. </ins> 8.4.1. Many of the request header fields for
Original text:
8.4.2. <del> The "Accept" header field can be used by user agents to specify response media types that are acceptable.  Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in- line image. </del>  The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all

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:
8.4.2.  <ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image. </ins> The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all
Original text:
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality". <del> A request without any Accept header field implies that the user agent will accept any media type in response.  If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a response or disregard the header field by treating the response as if it is not subject to content negotiation. </del> A more elaborate example is Verbally, this would be interpreted as "text/html and text/x-c are

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:
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality".  A more elaborate example is Verbally, this would be interpreted as "text/html and text/x-c are
Original text:
8.4.3. The "Accept-Charset" header field can be sent by a user agent to <del> indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </del>  Charset names are defined in charset.  A user agent MAY associate a quality value with each charset to indicate the user's relative

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:
8.4.3. The "Accept-Charset" header field can be sent by a user agent to  <ins> indicate its preferences for charsets in textual response content. For example, this field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </ins> Charset names are defined in charset.  A user agent MAY associate a quality value with each charset to indicate the user's relative
Original text:
The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept- <del> Charset field.  If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field are considered "not acceptable" to the client. A request without any Accept-Charset header field implies that the user agent will accept any charset in response.  Most general-purpose user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (fingerprinting). If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a response, or disregard the header field by treating the resource as if it is not subject to content negotiation. </del>  8.4.4. The "Accept-Encoding" header field can be used by user agents to <del> indicate what response content-codings (content.codings) are acceptable in the response.  An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred. </del>  Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in

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:
The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept-  <ins> Charset field. </ins> 8.4.4. The "Accept-Encoding" header field can be used by user agents to  <ins> indicate their preferences regarding response content-codings (content.codings).  An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred. </ins> Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in