jiebi/TextFlow huggingface dataset:
Original text:
This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864. <del> It defines both a new registration procedure and moves HTTP field definitions into a separate registry. </del>  Please create a new registry as outlined in fields.registry.

Reviewer comments:
The follow-up discussion on indicated that the nature of the updates to RFC 3864 is essentially a "partial obsoletes", which means that we do not want to be part of BCP 90 even if we could -- we're carving off a piece of it and branching out on our own. This PR attempts to reword the description slightly to indicate that we're not just tweaking part of RFC 3864, but rather replacing part of it (the parts that relate to HTTP), hopefully without bloating the text too much.

Revised text:
This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864.  <ins> It replaces the old procedures as they relate to HTTP, by defining a new registration procedure and moving HTTP field definitions into a separate registry. </ins> Please create a new registry as outlined in fields.registry.
Original text:
for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols.  Proxies are often used to group an organization's HTTP <del> requests through a common intermediary for the sake of security, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </del>  A

Reviewer comments:
Inspired by some discussion on : while just the word "security" is indeed used in marketing literature for proxies, it's meaning to different parties is so varied so as to not really convey much useful information. In the IETF we try hard to be clear about what security provides we need and/or provide, avoiding the vague catch-all term. However (as I am reminded out of band), the audience of this document is not exactly security experts, and it is easy to go overboard trying to be precise, at least in this instance. [actual commit message body retained below] The mere act of inserting a proxy into the chain does not, in and of itself, do much of anything for the security of the system (and a badly implemented proxy can make the security of the system much worse). A proxy can, however, provide security services such as auditing access, annotating content from untrustworthy sources, exfiltration avoidance, etc. It is these services that are the security-related motivation for using a proxy, so say that "security services", rather than just "security", are being provided by the proxy.

Revised text:
for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols.  Proxies are often used to group an organization's HTTP  <ins> requests through a common intermediary for the sake of security services, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </ins> A
Original text:
request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being <del> developed as an extension. </del>  12.3.

Reviewer comments:
It may or may not be useful to have an HTTP extension in order to perform reactive negotiation -- one possible approach that does not require an extension would be policy in the user-agent. In the spirit of "less is more", and to not overly constrain our forward-looking statement, just remove the phrase "as an extension". (inspired by follow-up discussions on )
I almost made the same edit earlier.

Revised text:
request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being  <ins> developed. </ins> 12.3.
Original text:
status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link-editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del>  The server SHOULD generate a

Reviewer comments:
The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.

Revised text:
status code indicates that the has been assigned a new permanent URI and any future references to  <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a
Original text:
status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del>  The server SHOULD generate a

Reviewer comments:
The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.

Revised text:
status code indicates that the has been assigned a new permanent URI and any future references to  <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a
Original text:
concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent processing of content received via HTTP, or secure use of the <del> Internet in general, rather than security of the protocol.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </del>  17.1.

Reviewer comments:
Inspired by follow-up discussions on , make a concrete proposal for how the RFC 3986 security considerations might be mentioned in our own security considerations. I understand the editors' stance on adding substantial new text at this point, and will defer to them on whether this constitutes "substantial".

Revised text:
concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent processing of content received via HTTP, or secure use of the  <ins> Internet in general, rather than security of the protocol.  The security considerations for URIs, which are fundamental to HTTP operation, are discussed in URI.  Various organizations maintain topical information and links to current research on Web application security (e.g., OWASP). </ins> 17.1.
Original text:
new registration procedure and moving HTTP field definitions into a separate registry. <del> Please create a new registry as outlined in fields.registry. </del>  After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to

Reviewer comments:
note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry

Revised text:
new registration procedure and moving HTTP field definitions into a separate registry.  <ins> Please create a new registry as outlined in fields.registry, and let that registry link to this specification (e.g., "See section fields.extensibility of [this document] for information on defining and registering new HTTP Header Fields."). </ins> After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to
Original text:
Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP field name registrations have moved, <del> with an appropriate link. </del>  After that is complete, please update the new registry with the field names listed in the following table.

Reviewer comments:
note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry

Revised text:
Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP field name registrations have moved,  <ins> with an appropriate link (such as: "HTTP field name registrations have been moved to <https://www.iana.org/assignments/http-fields> per [this document].") and furthermore remove the existing note pointing to RFC7231 ("See section 8.3.1 of [RFC7231] for information on registering new HTTP Header Fields."). </ins> After that is complete, please update the new registry with the field names listed in the following table.
Original text:
Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, <del> browsing history, browsing cache, or similar, are cleared. </del>  5.

Reviewer comments:
NAME - can you review?
The client hint spec does not seem to specify if there's a maximum lifetime for the origin opt-in preferences. There seem to be spec that the data should be cleared when site data, cookies, cache, etc. are cleared, but barring that should there be some sort of reasonable limit?
I'm new to this process; I'm not sure how to add the "client-hints" label
NAME thoughts? You were the one pushing for an implicit lifetime. Do we want to cap it?
I think that what you should say is that the browser can discard this state, but it should do so only when it drops all other state for the origin (e.g., when clearing cookies). Modeling this as part of origin-bound state like that is far easier to reason about and more reliable for sites.
We already have "Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared." Do we need to also add something around origin-bound state to that?
As Safari is already capping script-set storage lifetime to 7 days (Brave does w/ cookies, plans to do for all storage too), and some other vendors have hinted at the same, I suggest a max lifetime of 7 days. Especially given the possibility that these values can be tracking vectors (discussed in the fingerprinting conversation).
The text above means that browsers that choose to set max lifetime to storage/cookies will MUST do the same for Client Hints. I don't think we need to bake in the specific max age that some UAs chose into an IETF draft.
I hear what you're saying, but the purpose of a standard is not to say "some people will act X and some folks will act Y", its to bring X and Y as close as possible. What is the use case for a lifetime of > 7 days? Like any cache value, its perf utility decreases as life time increases, but the privacy risk stays constant. Put differently, what is the concern w/ a maximum value, to at least partially constrain the privacy risk?
Sounds like the restriction you're talking about is of larger scope than Client Hints, and applies the origin storage in general. I suggest you'd try to enforce those specific values e.g. on session cookies, and Client Hints will follow out of that. At the same time, I was under the impressions that when we , we tied the lifetime of Client-Hints persistence to session cookies, but looks like we did not. I'll submit a PR on that front.

Revised text:
Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data,  <ins> browsing history, browsing cache, cookies, or similar, are cleared. </ins> 5.
Original text:
behaviours, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the OWS and tchar rules from RFC7230. </del>  When parsing from HTTP header fields, implementations MUST follow the algorithms, but MAY vary in implementation so as the behaviours are

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
behaviours, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from  <ins> RFC5234.  It also includes the tchar rule from RFC7230. </ins> When parsing from HTTP header fields, implementations MUST follow the algorithms, but MAY vary in implementation so as the behaviours are
Original text:
Append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. <del> If more values remain in inner_list, append a single WS to </del>  output. Append ")" to output.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output.  <ins> If more values remain in inner_list, append a single SP to </ins> output. Append ")" to output.
Original text:
Append a COMMA to output. <del> Append a single WS to output. </del>  Return output.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Append a COMMA to output.  <ins> Append a single SP to output. </ins> Return output.
Original text:
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. <del> Discard any leading OWS from input_string. </del>  If header_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.  <ins> Discard any leading SP characters from input_string. </ins> If header_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.
Original text:
If header_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string. <del> Discard any leading OWS from input_string. </del>  If input_string is not empty, fail parsing.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
If header_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string.  <ins> Discard any leading SP characters from input_string. </ins> If input_string is not empty, fail parsing.
Original text:
Append the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string to members. <del> Discard any leading OWS from input_string. </del>  If input_string is empty, return members. Consume the first character of input_string; if it is not COMMA, fail parsing. <del> Discard any leading OWS from input_string. </del>  If input_string is empty, there is a trailing comma; fail parsing.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Append the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string to members.  <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, return members. Consume the first character of input_string; if it is not COMMA, fail parsing.  <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
Original text:
While input_string is not empty: <del> Discard any leading OWS from input_string. </del>  If the first character of input_string is ")":

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
While input_string is not empty:  <ins> Discard any leading SP characters from input_string. </ins> If the first character of input_string is ")":
Original text:
Add name this_key with value member to dictionary. <del> Discard any leading OWS from input_string. </del>  If input_string is empty, return dictionary. Consume the first character of input_string; if it is not COMMA, fail parsing. <del> Discard any leading OWS from input_string. </del>  If input_string is empty, there is a trailing comma; fail parsing.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Add name this_key with value member to dictionary.  <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, return dictionary. Consume the first character of input_string; if it is not COMMA, fail parsing.  <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
Original text:
Consume a ";" character from the beginning of input_string. <del> Discard any leading OWS from input_string. </del>  let param_name be the result of running Parsing a Key (parse- key) with input_string.

Reviewer comments:
An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.

Revised text:
Consume a ";" character from the beginning of input_string.  <ins> Discard any leading SP characters from input_string. </ins> let param_name be the result of running Parsing a Key (parse- key) with input_string.