jiebi/TextFlow huggingface dataset:
Original text:
Note that a Structured Header token allows the characters as the "token" ABNF rule defined in RFC7230, with the exceptions that the <del> first character is required to be ALPHA, and ":" and "/" are also allowed. </del>  3.3.5.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
Note that a Structured Header token allows the characters as the "token" ABNF rule defined in RFC7230, with the exceptions that the  <ins> first character is required to be either ALPHA or "*", and ":" and "/" are also allowed in subsequent characters. </ins> 3.3.5.
Original text:
The ABNF for a byte sequence in HTTP headers is: <del> In HTTP headers, a byte sequence is delimited with asterisks and encoded using base64 (RFC4648, Section 4).  For example: </del>  Parsers MUST support byte sequences with at least 16384 octets after decoding.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
The ABNF for a byte sequence in HTTP headers is:  <ins> In HTTP headers, a byte sequence is delimited with colons and encoded using base64 (RFC4648, Section 4).  For example: </ins> Parsers MUST support byte sequences with at least 16384 octets after decoding.
Original text:
Given a token as input_token, return an ASCII string suitable for use in a HTTP header value. <del> If input_token is not a sequence of characters, or contains a </del>  character not in tchar, ":" or "/", fail serialisation. Let output be an empty string.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
Given a token as input_token, return an ASCII string suitable for use in a HTTP header value.  <ins> If input_token is not a sequence of characters, the first character is not ALPHA or "*", or the remaining contain a </ins> character not in tchar, ":" or "/", fail serialisation. Let output be an empty string.
Original text:
Let output be an empty string. <del> Append "*" to output. </del>  Append the result of base64-encoding input_bytes as per RFC4648, Section 4, taking account of the requirements below. <del> Append "*" to output. </del>  Return output.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
Let output be an empty string.  <ins> Append ":" to output. </ins> Append the result of base64-encoding input_bytes as per RFC4648, Section 4, taking account of the requirements below.  <ins> Append ":" to output. </ins> Return output.
Original text:
Given an ASCII string as input_string, return a token. input_string is modified to remove the parsed value. <del> If the first character of input_string is not ALPHA, fail parsing. </del>  Let output_string be an empty string.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
Given an ASCII string as input_string, return a token. input_string is modified to remove the parsed value.  <ins> If the first character of input_string is not ALPHA or "*", fail parsing. </ins> Let output_string be an empty string.
Original text:
Given an ASCII string as input_string, return a byte sequence. input_string is modified to remove the parsed value. <del> If the first character of input_string is not "*", fail parsing. </del>  Discard the first character of input_string. <del> If there is not a "*" character before the end of input_string, </del>  fail parsing. Let b64_content be the result of consuming content of input_string <del> up to but not including the first instance of the character "*". </del>  <del> Consume the "*" character at the beginning of input_string. </del>  If b64_content contains a character not included in ALPHA, DIGIT, "+", "/" and "=", fail parsing.

Reviewer comments:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
Given an ASCII string as input_string, return a byte sequence. input_string is modified to remove the parsed value.  <ins> If the first character of input_string is not ":", fail parsing. </ins> Discard the first character of input_string.  <ins> If there is not a ":" character before the end of input_string, </ins> fail parsing. Let b64_content be the result of consuming content of input_string  <ins> up to but not including the first instance of the character ":". </ins>  <ins> Consume the ":" character at the beginning of input_string. </ins> If b64_content contains a character not included in ALPHA, DIGIT, "+", "/" and "=", fail parsing.
Original text:
result of running Parsing a String (parse-string) with input_string. <del> If the first character of input_string is "*", return the result </del>  of running Parsing a Byte Sequence (parse-binary) with input_string. If the first character of input_string is "?", return the result of running Parsing a Boolean (parse-boolean) with input_string. <del> If the first character of input_string is an ALPHA, return the result of running Parsing a Token (parse-token) with input_string. </del>  Otherwise, the item type is unrecognized; fail parsing.

Reviewer comments:
Missed in
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Revised text:
result of running Parsing a String (parse-string) with input_string.  <ins> If the first character of input_string is ":", return the result </ins> of running Parsing a Byte Sequence (parse-binary) with input_string. If the first character of input_string is "?", return the result of running Parsing a Boolean (parse-boolean) with input_string.  <ins> If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (parse-token) with input_string. </ins> Otherwise, the item type is unrecognized; fail parsing.
Original text:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "decimal". </del>  Otherwise, prepend char to input_string, and exit the loop.

Reviewer comments:
Explicitly disallow thirteen digits before the dot.
NAME I think this is the right way to validate the number of digits in a decimal.

Revised text:
If char is a DIGIT, append it to input_number.  <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop.
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, "example.com"'s public suffix is "com".  User agents SHOULD </del>  use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. An origin's "registered domain" is the origin's host's public suffix <del> plus the label to its left.  That is, for "https://www.example.com", the public suffix is "com", and the registered domain is "example.com".  This concept is defined more rigorously in PSL, and </del>  is also known as "effective top-level domain plus one" (eTLD+1). The term "request", as well as a request's "client", "current url",

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:
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 "com".  User agents SHOULD </ins> use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. An origin's "registered domain" is the origin's host's public suffix  <ins> plus the label to its left.  That is, for "https://www.site.example", the public suffix is "example", and the registered domain is "site.example".  This concept is defined more rigorously in PSL, and </ins> is also known as "effective top-level domain plus one" (eTLD+1). The term "request", as well as a request's "client", "current url",
Original text:
The server can alter the default scope of the cookie using the Path and Domain attributes.  For example, the server can instruct the user agent to return the cookie to every path and every subdomain of <del> example.com. </del>  As shown in the next example, the server can store multiple cookies at the user agent.  For example, the server can store a session

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:
The server can alter the default scope of the cookie using the Path and Domain attributes.  For example, the server can instruct the user agent to return the cookie to every path and every subdomain of  <ins> site.example. </ins> As shown in the next example, the server can store multiple cookies at the user agent.  For example, the server can store a session
Original text:
The "SameSite" attribute limits the scope of the cookie such that it will only be attached to requests if those requests are same-site, as defined by the algorithm in same-site-requests.  For example, <del> requests for "https://example.com/sekrit-image" will attach same-site cookies if and only if initiated from a context whose "site for cookies" is "example.com". </del>  If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests.  If the value is "Lax", the

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:
The "SameSite" attribute limits the scope of the cookie such that it will only be attached to requests if those requests are same-site, as defined by the algorithm in same-site-requests.  For example,  <ins> requests for "https://site.example/sekrit-image" will attach same- site cookies if and only if initiated from a context whose "site for cookies" is "site.example". </ins> If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests.  If the value is "Lax", the
Original text:
For example, the following cookies would always be rejected: While the would be accepted if set from a secure origin (e.g. <del> "https://example.com/"), and rejected otherwise: </del>  4.2.

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:
For example, the following cookies would always be rejected: While the would be accepted if set from a secure origin (e.g.  <ins> "https://site.example/"), and rejected otherwise: </ins> 4.2.
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 is essential for preventing attacker.com from disrupting the <del> integrity of example.com by setting a cookie with a Domain </del>  attribute of "com".  Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix

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:
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 is essential for preventing attacker.com from disrupting the  <ins> integrity of site.example by setting a cookie with a Domain </ins> attribute of "com".  Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix