jiebi/TextFlow huggingface dataset:
Original text:
Abstract <del> An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. </del>  <del> This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this.  They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. </del>  Note to Readers

Reviewer comments:
Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.

Revised text:
Abstract  <ins> HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers.  In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. </ins>  <ins> This specification defines a response header, Accept-CH, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." It also defines an initial set of Client Hints. </ins> Note to Readers
Original text:
field identified by a content negotiation mechanism that the implementation supports: <del> Let request-value be the field-value(s) associated with field-name in incoming-request. </del>  Let available-values be a list containing all available- value for variant.

Reviewer comments:
This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.

Revised text:
field identified by a content negotiation mechanism that the implementation supports:  <ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. </ins> Let available-values be a list containing all available- value for variant.
Original text:
MUST define an algorithm for selecting a result.  It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header <del> nominated above and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </del>  backports fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.

Reviewer comments:
This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.

Revised text:
MUST define an algorithm for selecting a result.  It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header  <ins> nominated above (or null if the request header is absent) and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </ins> backports fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.
Original text:
as shown here. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in Section 7 of RFC7230, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del>  <del> Additionally, it uses the "field-name", "OWS" and "token" rules from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </del>  2.

Reviewer comments:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Revised text:
as shown here. This specification uses the Augmented Backus-Naur Form (ABNF)  <ins> notation of RFC5234 but relies on Structured Headers from I-D.ietf- httpbis-header-structure for parsing. </ins>  <ins> Additionally, it uses the "field-name" rule from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </ins> 2.
Original text:
Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages.  Note <del> that, as with all HTTP header fields that use the "#" list rule (see RFC7230, Section 7), they might occur in the same header field or separately, like this: </del>  The ordering of available-values after the field-name is significant, as it might be used by the header's algorithm for selecting a

Reviewer comments:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Revised text:
Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages.  Note  <ins> that, as with all Structured Header lists, they might occur in the same header field or separately, like this: </ins> The ordering of available-values after the field-name is significant, as it might be used by the header's algorithm for selecting a
Original text:
This algorithm computes the cross-product of the elements of key- facets. <del> Given key-facets (a list of lists), and key-stub (a string representing a partial key), and possible-keys (a list): </del>  Let values be the first member of key-facets. <del> For each value in values: If key-stub is an empty string, let this-key be a copy of value. </del>  <del> Otherwise: Let this-key be a copy of key-stub. Append a semicolon (";") to this-key. </del>  <del> Append value to this-key. </del>  <del> Let remaining-facets be a copy of all of the members of key- facets except the first. </del>  If remaining-facets is empty, append this-key to possible-keys.

Reviewer comments:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Revised text:
This algorithm computes the cross-product of the elements of key- facets.  <ins> Given key-facets (a list of lists of strings), and key-stub (a list of strings representing a partial key), and possible-keys (a list of lists of strings): </ins> Let values be the first member of key-facets.  <ins> Let remaining-facets be a copy of all of the members of key-facets except the first. </ins>  <ins> For each value in values: </ins>  <ins> Let this-key be a copy of key-stub. </ins>  <ins> Append value to this-key. </ins> If remaining-facets is empty, append this-key to possible-keys.
Original text:
Then the sorted-variants would be: <del> Which means that the sorted-keys would be: </del>  Representing a first preference of a French, gzip'd response.  Thus, if a cache has a response with:

Reviewer comments:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Revised text:
Then the sorted-variants would be:  <ins> Which means that the result of the cache algorithm would be: </ins> Representing a first preference of a French, gzip'd response.  Thus, if a cache has a response with:
Original text:
More generally, application protocols using HTTP face a number of design decisions, including: <del> Should it define a new URL scheme?  Use new ports? </del>  Should it use standard HTTP methods and status codes, or define new ones?

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
More generally, application protocols using HTTP face a number of design decisions, including:  <ins> Should it define a new URI scheme?  Use new ports? </ins> Should it use standard HTTP methods and status codes, or define new ones?
Original text:
the transport port in use is 80 or 443, <del> the URL scheme "http" or "https" is used, </del>  the ALPN protocol ID RFC7301 generically identifies HTTP (e.g., "http/1.1", "h2", "h2c"), or

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
the transport port in use is 80 or 443,  <ins> the URI scheme "http" or "https" is used, </ins> the ALPN protocol ID RFC7301 generically identifies HTTP (e.g., "http/1.1", "h2", "h2c"), or
Original text:
adaptable to these changes, and as the protocol diverges from HTTP, the benefit of mindshare will be lost. <del> Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, </del>  transport ports, ALPN protocol IDs or IANA registries; rather, they are encouraged to establish their own.

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
adaptable to these changes, and as the protocol diverges from HTTP, the benefit of mindshare will be lost.  <ins> Protocols that are based upon HTTP MUST NOT reuse HTTP's URI schemes, </ins> transport ports, ALPN protocol IDs or IANA registries; rather, they are encouraged to establish their own.
Original text:
can cause deployment issues, and is therefore bad practice in standards. <del> Instead of statically defining URL components like paths, it is </del>  RECOMMENDED that applications using HTTP define links in payloads, to allow flexibility in deployment.

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
can cause deployment issues, and is therefore bad practice in standards.  <ins> Instead of statically defining URI components like paths, it is </ins> RECOMMENDED that applications using HTTP define links in payloads, to allow flexibility in deployment.
Original text:
Instead, applications are encouraged to ensure that URLs are discovered at runtime, allowing HTTP-based services to describe their own capabilities.  One way to do this is to use typed links RFC8288 <del> to convey the URIs that are in use, as well as the semantics of the </del>  resources that they identify.  See resource for details. 4.4.1.

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
Instead, applications are encouraged to ensure that URLs are discovered at runtime, allowing HTTP-based services to describe their own capabilities.  One way to do this is to use typed links RFC8288  <ins> to convey the URLs that are in use, as well as the semantics of the </ins> resources that they identify.  See resource for details. 4.4.1.
Original text:
4.4.2. Applications that use HTTP will typically employ the "http" and/or <del> "https" URL schemes. "https" is RECOMMENDED to provide </del>  authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks RFC7258. However, application-specific schemes can also be defined.  When <del> defining an URL scheme for an application using HTTP, there are a </del>  number of tradeoffs and caveats to keep in mind: Unmodified Web browsers will not support the new scheme.  While it <del> is possible to register new URL schemes with Web browsers (e.g. </del>  registerProtocolHandler() in HTML5, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
4.4.2. Applications that use HTTP will typically employ the "http" and/or  <ins> "https" URI schemes. "https" is RECOMMENDED to provide </ins> authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks RFC7258. However, application-specific schemes can also be defined.  When  <ins> defining an URI scheme for an application using HTTP, there are a </ins> number of tradeoffs and caveats to keep in mind: Unmodified Web browsers will not support the new scheme.  While it  <ins> is possible to register new URI schemes with Web browsers (e.g. </ins> registerProtocolHandler() in HTML5, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.
Original text:
Web features that require a secure context SECCTXT will likely treat a new scheme as insecure. <del> See RFC7595 for more information about minting new URL schemes. </del>  4.4.3.

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
Web features that require a secure context SECCTXT will likely treat a new scheme as insecure.  <ins> See RFC7595 for more information about minting new URI schemes. </ins> 4.4.3.
Original text:
expensive process. In some cases, however, GET might be unwieldy for expressing queries, <del> because of the limited syntax of the URL; in particular, if binary </del>  data forms part of the query terms, it needs to be encoded to conform <del> to URL syntax. </del>  While this is not an issue for short queries, it can become one for larger query terms, or ones which need to sustain a high rate of

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
expensive process. In some cases, however, GET might be unwieldy for expressing queries,  <ins> because of the limited syntax of the URI; in particular, if binary </ins> data forms part of the query terms, it needs to be encoded to conform  <ins> to URI syntax. </ins> While this is not an issue for short queries, it can become one for larger query terms, or ones which need to sustain a high rate of
Original text:
to identify clients.  The Basic authentication scheme RFC7617 MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS" <del> URL scheme, or another using TLS).  The Digest scheme RFC7616 MUST </del>  NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5".

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
to identify clients.  The Basic authentication scheme RFC7617 MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS"  <ins> URI scheme, or another using TLS).  The Digest scheme RFC7616 MUST </ins> NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5".
Original text:
other than specified. Applications that use HTTP in a manner that involves modification of <del> implementations - for example, requiring support for a new URL </del>  scheme, or a non-standard method - risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security

Reviewer comments:
This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL

Revised text:
other than specified. Applications that use HTTP in a manner that involves modification of  <ins> implementations - for example, requiring support for a new URI </ins> scheme, or a non-standard method - risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security