jiebi/TextFlow huggingface dataset:
Original text:
top-level navigations. Consider the scenario in which a user reads their email at MegaCorp <del> Inc's webmail provider "https://example.com/".  They might expect that clicking on an emailed link to "https://projects.com/secret/ </del>  project" would show them the secret project that they're authorized <del> to see, but if "projects.com" has marked their session cookies as </del>  "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

Reviewer comments:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Revised text:
top-level navigations. Consider the scenario in which a user reads their email at MegaCorp  <ins> Inc's webmail provider "https://site.example/".  They might expect that clicking on an emailed link to "https://projects.example/secret/ </ins> project" would show them the secret project that they're authorized  <ins> to see, but if "projects.example" has marked their session cookies as </ins> "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.
Original text:
The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For <del> example, "site.example"'s public suffix is "com".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </del>  An origin's "registered domain" is the origin's host's public suffix plus the label to its left.  That is, for "https://www.site.example",

Reviewer comments:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Revised text:
The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For  <ins> example, "site.example"'s public suffix is "example".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </ins> An origin's "registered domain" is the origin's host's public suffix plus the label to its left.  That is, for "https://www.site.example",
Original text:
NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step <del> is essential for preventing attacker.com from disrupting the integrity of site.example by setting a cookie with a Domain attribute of "com".  Unfortunately, the set of public suffixes </del>  (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at

Reviewer comments:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Revised text:
NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step  <ins> is essential for preventing "attacker.example" from disrupting the integrity of "site.example" by setting a cookie with a Domain attribute of "example".  Unfortunately, the set of public suffixes </ins> (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at
Original text:
project" would show them the secret project that they're authorized to see, but if "projects.example" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along <del> with the request. "projects.com" will render a 404 error to avoid </del>  leaking secret information, and the user will be quite confused. Developers can avoid this confusion by adopting a session management

Reviewer comments:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Revised text:
project" would show them the secret project that they're authorized to see, but if "projects.example" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along  <ins> with the request. "projects.example" will render a 404 error to avoid </ins> leaking secret information, and the user will be quite confused. Developers can avoid this confusion by adopting a session management
Original text:
4.1.5. <del> Given a decimal_number as input_decimal, return an ASCII string </del>  suitable for use in a HTTP field value.  Let output be an empty string. If input_decimal is less than (but not equal to) 0, append "-" to

Reviewer comments:
Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.

Revised text:
4.1.5.  <ins> Given a decimal number as input_decimal, return an ASCII string </ins> suitable for use in a HTTP field value. <ins> If input_decimal is not a decimal number, fail serialisation. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialisation. </ins> Let output be an empty string. If input_decimal is less than (but not equal to) 0, append "-" to
Original text:
Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". <del> If the number of characters appended in the previous step is greater than 12, fail serialisation. </del> Append "." to output. If input_decimal's fractional component is zero, append "0" to output. <del> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal </del>  digits) to output. <del> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </del> Return output. 4.1.6.

Reviewer comments:
Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.

Revised text:
Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".  Append "." to output. If input_decimal's fractional component is zero, append "0" to output.  <ins> Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal </ins> digits) to output.  Return output. 4.1.6.
Original text:
3.3. <del> An item is can be a integer (integer), decimal (decimal), string </del>  (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Reviewer comments:
Small editorial fix. I'm also not comfortable with "a integer", maybe remove "a"? Anyway that's a nitpick.
Thanks NAME
LGTM

Revised text:
3.3.  <ins> An item can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).
Original text:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described <del> in section 2.1), which is only a speedbump along the road to </del>  exploitation. Features like "<link rel='prerender'>" prerendering can be

Reviewer comments:
NAME I'm just going to land this (as it's trivial), and roll an -05 today.
This should use a named section reference, no? Otherwise it can break again when section numbers change.
In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!

Revised text:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described  <ins> in section 5.2.1), which is only a speedbump along the road to </ins> exploitation. Features like "<link rel='prerender'>" prerendering can be
Original text:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described <del> in section 5.2.1), which is only a speedbump along the road to </del>  exploitation. Features like "<link rel='prerender'>" prerendering can be

Reviewer comments:
In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!

Revised text:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described  <ins> in document-requests), which is only a speedbump along the road to </ins> exploitation. Features like "<link rel='prerender'>" prerendering can be
Original text:
If more member_values remain in input_list: <del> Append a COMMA to output. </del>  Append a single SP to output.

Reviewer comments:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Revised text:
If more member_values remain in input_list:  <ins> Append "," to output. </ins> Append a single SP to output.
Original text:
If more members remain in input_dictionary: <del> Append a COMMA to output. </del>  Append a single SP to output.

Reviewer comments:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Revised text:
If more members remain in input_dictionary:  <ins> Append "," to output. </ins> Append a single SP to output.
Original text:
If input_string is empty, return members. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del>  Discard any leading SP characters from input_string.

Reviewer comments:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Revised text:
If input_string is empty, return members.  <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.
Original text:
If input_string is empty, return dictionary. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del>  Discard any leading SP characters from input_string.

Reviewer comments:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Revised text:
If input_string is empty, return dictionary.  <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.
Original text:
HTTP Client Hints <del> draft-ietf-httpbis-client-hints-08 </del>  Abstract

Reviewer comments:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Revised text:
HTTP Client Hints  <ins> draft-ietf-httpbis-client-hints-10 </ins> Abstract
Original text:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared. <del> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. 5.1. </del>  Deployment of new request headers requires several considerations:

Reviewer comments:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Revised text:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared.  <ins> 4.2. </ins> Deployment of new request headers requires several considerations:
Original text:
Doing so makes them easier to identify programmatically (e.g., for stripping unrecognised hints from requests by privacy filters). <del> 5.2. </del>  A user agent that tracks access to active fingerprinting information SHOULD consider emission of Client Hints headers similarly to the way

Reviewer comments:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Revised text:
Doing so makes them easier to identify programmatically (e.g., for stripping unrecognised hints from requests by privacy filters).  <ins> 4.3. </ins> A user agent that tracks access to active fingerprinting information SHOULD consider emission of Client Hints headers similarly to the way
Original text:
and from those without.  This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use.  6. This document defines the "Accept-CH" HTTP response field, and

Reviewer comments:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Revised text:
and from those without.  This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use. <ins> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. </ins> 6. This document defines the "Accept-CH" HTTP response field, and
Original text:
the server. An origin can use the Priority response header field to indicate its <del> view on how an HTTP response should be prioritized.  When forwarding an HTTP response with the Priority response header field, an intermediary can use the parameters being found in that response instead of those found in the request. </del>  Absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value.  This is

Reviewer comments:
We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!

Revised text:
the server. An origin can use the Priority response header field to indicate its  <ins> view on how an HTTP response should be prioritized.  An intermediary that forwards an HTTP response can use the parameters found in the Priority response header field, in combination with the client Priority request header field, as input to its prioritization process.  No guidance is provided for merging priorities, this is left as an implementation decision. </ins> Absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value.  This is
Original text:
in which omission of a priority parameter implies the use of their default values (see #parameters). <del> For example, when the client sends an HTTP request with </del>  and the origin responds with the intermediary might alter its understanding of the urgency from <del> "5" to "1", because the server-provided value overrides the value provided by the client.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </del>  incremental("i") parameter. 7.

Reviewer comments:
We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!

Revised text:
in which omission of a priority parameter implies the use of their default values (see #parameters).  <ins> As a non-normative example, when the client sends an HTTP request with </ins> and the origin responds with the intermediary might alter its understanding of the urgency from  <ins> "5" to "1", because it prefers the server-provided value over the client's.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </ins> incremental("i") parameter. 7.
Original text:
configuration, or by consulting if that request contains one of the following header fields: <del> CDN-Loop (RFC8586) </del> Forwarded, X-Forwarded-For (RFC7239) Via (RFC7230, Section 5.7.1)

Reviewer comments:
cc: NAME
Thank you for the fix.
RFC8586 is very clear about other uses of : The current priority draft uses it to detect whether there upstream intermediaries, not loop detection. This should be removed.

Revised text:
configuration, or by consulting if that request contains one of the following header fields:  Forwarded, X-Forwarded-For (RFC7239) Via (RFC7230, Section 5.7.1)
Original text:
than needing to subvert DNS or IP routing in order to use a compromised certificate, a malicious server now only needs a client to connect to _some_ HTTPS site under its control in order to present <del> the compromised certificate.  As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </del>  One such means is the Required Domain certificate extension defined in {extension}. Clients MUST require that server certificates

Reviewer comments:
The intent here is to say that your requirements for trusting a secondary certificate should be at least as strict as for trusting additional names in the primary certificate.
Add text noting the DNS check / not-check guidance in RFCs 7540 and 8336, respectively. Explicitly side-step the issue by saying that if you would do a DNS lookup for a hostname in the primary cert, you MUST do the DNS check for a hostname in a secondary cert as well; if you would omit the DNS lookup for a hostname in the primary cert, you MAY omit the DNS check for a hostname in the secondary cert as well.

Revised text:
than needing to subvert DNS or IP routing in order to use a compromised certificate, a malicious server now only needs a client to connect to _some_ HTTPS site under its control in order to present  <ins> the compromised certificate.  Clients SHOULD consult DNS for hostnames presented in secondary certificates if they would have done so for the same hostname if it were present in the primary certificate. As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </ins> One such means is the Required Domain certificate extension defined in {extension}. Clients MUST require that server certificates