jiebi/TextFlow huggingface dataset:
Original text:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> If member_value is Boolean true: </del>  <del> Append the result of running Serializing Parameters (ser- params) with parameters to output. </del>  <del> Otherwise: </del>  <del> Append "=" to output. </del>  <del> If member_value is an array, append the result of running Serializing an Inner List (ser-innerlist) with (member_value, parameters) to output. </del>  <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del>  <del> If more members remain in input_dictionary: </del>  <del> Append "," to output. </del>  <del> Append a single SP to output. </del>  Return output.

Reviewer comments:
NAME noticed that is messed up. I think the fix is to indent the top-level 2-5 -- but I want to have a good look at it, compare to implementation, and I'd like others to verify, as I'm wary of making changes at this late stage. Blame seems to be , which I vaguely remember as being... surprising. That will teach me to slow down when something weird happens with Git...
Ping NAME NAME NAME to look over my shoulder...
Looking at URL the problem is that what became top-level 3 and 4 should have been steps inside top-level 2. Further changes have happened so now that applies to top-level 5 as well. (Top-level 2 itself seems good as that initiates the loop.) (Other for each statements do appear to have correct indenting.)
Like that?
Looks good to me.

Revised text:
Append the result of running Serializing a Key (ser-key) with member's member_name to output.  <ins> If member_value is Boolean true: </ins>  <ins> Append the result of running Serializing Parameters (ser- params) with parameters to output. </ins>  <ins> Otherwise: </ins>  <ins> Append "=" to output. </ins>  <ins> If member_value is an array, append the result of running Serializing an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins>  <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins>  <ins> If more members remain in input_dictionary: </ins>  <ins> Append "," to output. </ins>  <ins> Append a single SP to output. </ins> Return output.
Original text:
granularity for prioritizing responses for ordinary web browsing, at minimal complexity. <del> The value is encoded as an sh-integer.  The default value is 1. </del>  This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the

Reviewer comments:
When we discussed removing the semantics of urgency levels, we also thought it would be a good idea to change the default from 1 to 3. We agreed to do this and landed a change that removed the semantic text but unfortunately forgot to also change the default. This change simple fixes the oversight.
See URL for background
Thank you for the fix!

Revised text:
granularity for prioritizing responses for ordinary web browsing, at minimal complexity.  <ins> The value is encoded as an sh-integer.  The default value is 3. </ins> This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the
Original text:
For example, the following cookies would always be rejected: <del> While the would be accepted if set from a secure origin (e.g. "https://site.example/"), and rejected otherwise: </del>  4.2.

Reviewer comments:
Add what seems to be a missing word in the __Host example text.
Thanks!
Thank you!

Revised text:
For example, the following cookies would always be rejected:  <ins> While the following would be accepted if set from a secure origin (e.g.  "https://site.example/"), and rejected otherwise: </ins> 4.2.
Original text:
7. <del> 7.1. </del>  As a general guideline, a server SHOULD NOT use priority information for making schedule decisions across multiple connections, unless it

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
7.  <ins> A client MAY use priority values to make local scheduling choices about the requests it initiates. 8. </ins> As a general guideline, a server SHOULD NOT use priority information for making schedule decisions across multiple connections, unless it
Original text:
next hop that the connection is NOT coalesced (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). <del> 7.1.1. </del>  When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
next hop that the connection is NOT coalesced (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).  <ins> 8.1. </ins> When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend
Original text:
would receive less bandwidth in case the bottleneck exists between the server and the intermediary. <del> 7.1.2. </del>  It is common for CDN infrastructure to support different HTTP versions on the front end and back end.  For instance, the client-

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
would receive less bandwidth in case the bottleneck exists between the server and the intermediary.  <ins> 8.2. </ins> It is common for CDN infrastructure to support different HTTP versions on the front end and back end.  For instance, the client-
Original text:
can be scoped to individual end clients.  Authentication and other session information might provide this linkability. <del> 7.1.3. </del>  It is sometimes beneficial to deprioritize the transmission of one connection over others, knowing that doing so introduces a certain

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
can be scoped to individual end clients.  Authentication and other session information might provide this linkability.  <ins> 8.3. </ins> It is sometimes beneficial to deprioritize the transmission of one connection over others, knowing that doing so introduces a certain
Original text:
software update images.  Doing so improves responsiveness of other connections at the cost of delaying the delivery of updates. <del> Also, a client MAY use the priority values for making local scheduling choices for the requests it initiates. 8. </del>  Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- hop frame, the Priority header field is defined as end-to-end.

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
software update images.  Doing so improves responsiveness of other connections at the cost of delaying the delivery of updates.  <ins> 9. </ins> Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- hop frame, the Priority header field is defined as end-to-end.
Original text:
textual value makes the prioritization scheme extensible; see the discussion below. <del> 9. </del>  This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864:

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
textual value makes the prioritization scheme extensible; see the discussion below.  <ins> 10. TBD 11. </ins> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864:
Original text:
This document <del> 10.  References </del>  <del> 10.1.  URIs </del>  [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Reviewer comments:
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.

Revised text:
This document  <ins> 12.  References </ins>  <ins> 12.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Original text:
state.  This state can be limited by adopting the guidance about concurrency limits described above.  Extensible priorities is subject to a similar consideration because PRIORITY_UPDATE frames may arrive <del> before the request that they reference.  A server could retain the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </del>  barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer.  TODO: so what can we suggest?

Reviewer comments:
Since fairness is being moved out of security considerations, (URL) it makes the section empty. Seems reasonable to add some prose about the considerations of this scheme as compared to HTTP/2. However, this also depends on the outcome of the reprioritization discussion, so I'm being a little weasly with TBD and TODOs. Might want to just hold onto this for a while but WDYT NAME ?
Thank you for working on this. LGTM modulo the point below.

Revised text:
state.  This state can be limited by adopting the guidance about concurrency limits described above.  Extensible priorities is subject to a similar consideration because PRIORITY_UPDATE frames may arrive  <ins> before the request that they reference.  A server is required to store the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </ins> barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer.  TODO: so what can we suggest?
Original text:
2.1. <del> An HTTP header field value is identified by its header field name. While HTTP header field names are case-insensitive, implementations SHOULD use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </del>  An HTTP header field value is canonicalized as follows:

Reviewer comments:
Strengthened requirement for content identifiers for header fields to be lower-case (changed from SHOULD to MUST). Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier’s requirements. Minor editorial corrections and readability improvements.
The current text allows mixed-case header field names when they are being used as content identifiers. This is unnecessary – header field names are case-insensitive – and creates opportunity for incompatibility. Instead, content identifiers should always be lowercase.
The processing instructions for Creation Time and Expiration Time imply that verifiers are not permitted to account for clock skew during signature verification.
This can safely be fixed adding a -like claim, so that the signer remains in control of the signature validity. This is especially important if the signature is created with the signer's private key. imho this kind of document should not define a clock-skew tolerance threshold, and implementors shoud be suggested to fix their clocks. There may be corner cases (eg. IoT/disconnected devices ) that we should address properly
I'd split the clock-skew part in a separate PR. The rest LGTM.

Revised text:
2.1.  <ins> An HTTP header field is identified by its header field name.  While HTTP header field names are case-insensitive, implementations MUST use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </ins> An HTTP header field value is canonicalized as follows:
Original text:
The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's <del> Covered Content.  Each identifier MUST be one of those defined in Section 2.  This list MUST NOT be empty, as this would result in creating a signature over the empty string.  If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request-target) in the list.  If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list.  Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </del>  For example, given the following HTTP message:

Reviewer comments:
Strengthened requirement for content identifiers for header fields to be lower-case (changed from SHOULD to MUST). Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier’s requirements. Minor editorial corrections and readability improvements.
The current text allows mixed-case header field names when they are being used as content identifiers. This is unnecessary – header field names are case-insensitive – and creates opportunity for incompatibility. Instead, content identifiers should always be lowercase.
The processing instructions for Creation Time and Expiration Time imply that verifiers are not permitted to account for clock skew during signature verification.
This can safely be fixed adding a -like claim, so that the signer remains in control of the signature validity. This is especially important if the signature is created with the signer's private key. imho this kind of document should not define a clock-skew tolerance threshold, and implementors shoud be suggested to fix their clocks. There may be corner cases (eg. IoT/disconnected devices ) that we should address properly
I'd split the clock-skew part in a separate PR. The rest LGTM.

Revised text:
The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's  <ins> Covered Content. Each identifier MUST be one of those defined in Section 2. This list MUST NOT be empty, as this would result in creating a signature over the empty string. If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request- target) in the list. If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list. Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </ins> For example, given the following HTTP message:
Original text:
Remove any leading or trailing WSP characters from the name string and the value string. <del> If both the name string and the value string are empty, ignore the set-cookie-string entirely. </del> The cookie-name is the name string, and the cookie-value is the value string.

Reviewer comments:
Fixes .
Done
Currently according to the spec, any cookies set with a header should be ignored if their name and value are empty. However, this check is not applied in section 5.4 of the spec, and as a result the CookieStore had a allowed for sites to work around this check. To me, this is a symptom of a bigger issue: 6265bis treats non-HTTP cookies as an afterthought, . I think it's worth opening a separate issue just to track whether we add the empty-name-empty-value check to 5.4 of 6265bis, and if there are other checks on the header in 5.3 that are implied in 5.4 but not made explicit.
CC NAME
As you've noticed, the document currently assumes that 5.4 is only going to be exercised after 5.3. I think this particular issue is distinct from the issue you raise in the other bug, as the only non-HTTP APIs that existed before the async API you're working through used cookie strings, which were parsed just as the header was. Given that new mechanism, it does make sense to move "If both the name string and the value string are empty, ignore the set-cookie-string entirely." from 5.3 to 5.4. Skimming through, I think that's the only restriction that causes cookies to be ignored at the parsing stage.
Minor change so that we won't break "links" if ordering changes, and to explain the change.

Revised text:
Remove any leading or trailing WSP characters from the name string and the value string.  The cookie-name is the name string, and the cookie-value is the value string.
Original text:
"third-party" responses or the user agent might not wish to store cookies that exceed some size.  Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.

Reviewer comments:
Fixes .
Done
Currently according to the spec, any cookies set with a header should be ignored if their name and value are empty. However, this check is not applied in section 5.4 of the spec, and as a result the CookieStore had a allowed for sites to work around this check. To me, this is a symptom of a bigger issue: 6265bis treats non-HTTP cookies as an afterthought, . I think it's worth opening a separate issue just to track whether we add the empty-name-empty-value check to 5.4 of 6265bis, and if there are other checks on the header in 5.3 that are implied in 5.4 but not made explicit.
CC NAME
As you've noticed, the document currently assumes that 5.4 is only going to be exercised after 5.3. I think this particular issue is distinct from the issue you raise in the other bug, as the only non-HTTP APIs that existed before the async API you're working through used cookie strings, which were parsed just as the header was. Given that new mechanism, it does make sense to move "If both the name string and the value string are empty, ignore the set-cookie-string entirely." from 5.3 to 5.4. Skimming through, I think that's the only restriction that causes cookies to be ignored at the parsing stage.
Minor change so that we won't break "links" if ordering changes, and to explain the change.

Revised text:
"third-party" responses or the user agent might not wish to store cookies that exceed some size. <ins> If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely. </ins> Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.
Original text:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload body and message body.  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </del>  This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range <del> Requests or methods such as HEAD, while the message body is dependent on transfer codings and other transformations: resource- </del>  representation contains several examples to help illustrate those effects.

Reviewer comments:
HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)

Revised text:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of  <ins> the payload body (see Section 7.3.3 of SEMANTICS).  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the payload body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range  <ins> Requests or methods such as HEAD, while the way the payload body is transferred "on the wire" is dependent on other transformations (eg. transfer codings for HTTP/1.1 see 6.1 of HTTP11): resource- </ins> representation contains several examples to help illustrate those effects.