jiebi/CodeConvo huggingface dataset:
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 6.1.2 of I-D.ietf-httpbis-semantics) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </del> <ins> no content codings (see Section 6.1.2 of SEMANTICS) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </ins> 1.3.
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405 along with the "#rule" extension defined in Section 4 of <del> I-D.ietf-httpbis-semantics. </del> <ins> SEMANTICS. </ins> The definitions "representation", "selected representation", "representation data", "representation metadata", and "payload body" <del> in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. </del> <ins> in this document are to be interpreted as described in SEMANTICS. </ins> The definition "validator fields" in this document is to be <del> interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </del> <ins> interpreted as described in Section 10.2 of SEMANTICS. </ins> 2. The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of the payload body and message body.  It uses the representation data <del> (see Section 6.1 of I-D.ietf-httpbis-semantics), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> (see Section 6.1 of SEMANTICS), that can be fully or partially contained in the message 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
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: The resource is specified by the effective request URI and any "validator field" contained in the message. <del> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not- request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </del> <ins> The relationship between Content-Location (see Section 6.2.5 of SEMANTICS) and Digest is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </ins> A Digest field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: computation.  For some algorithms, one or more parameters can be supplied. <del> The BNF for "parameter" is defined in Section 4.4.1.4 of I-D.ietf- httpbis-semantics.  All digest-algorithm values are case-insensitive. </del> <ins> The BNF for "parameter" is defined in Section 4.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: (see acting-on-resources). The representation enclosed in the response refers to the resource <del> identified by "Content-Location" (see I-D.ietf-httpbis-semantics Section 6.3.2). </del> <ins> identified by "Content-Location" (see SEMANTICS Section 6.3.2). </ins> "Digest" is thus computed on the enclosed representation.
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: 12.10. This section registers the "Want-Digest" field in the "Hypertext <del> Transfer Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis- semantics. </del> <ins> Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Want-Digest"
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: 12.11. This section registers the "Digest" field in the "Hypertext Transfer <del> Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis-semantics. </del> <ins> Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Digest"
Code change:
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.

Related discussion:
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> <ins> If member_value is Boolean true: </ins> <del> Append the result of running Serializing Parameters (ser- params) with parameters to output. </del> <ins> Append the result of running Serializing Parameters (ser- params) with parameters to output. </ins> <del> Otherwise: </del> <ins> Otherwise: </ins> <del> Append "=" to output. </del> <ins> Append "=" to output. </ins> <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> <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> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> <del> If more members remain in input_dictionary: </del> <ins> If more members remain in input_dictionary: </ins> <del> Append "," to output. </del> <ins> Append "," to output. </ins> <del> Append a single SP to output. </del> <ins> Append a single SP to output. </ins> Return output.
Code change:
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!

Related discussion:
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> <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
Code change:
Add what seems to be a missing word in the __Host example text.
Thanks!
Thank you!

Related discussion:
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> <ins> While the following would be accepted if set from a secure origin (e.g.  "https://site.example/"), and rejected otherwise: </ins> 4.2.
Code change:
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.

Related discussion:
text: 7. <del> 7.1. </del> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
text: would receive less bandwidth in case the bottleneck exists between the server and the intermediary. <del> 7.1.2. </del> <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-
Code change:
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.

Related discussion:
text: can be scoped to individual end clients.  Authentication and other session information might provide this linkability. <del> 7.1.3. </del> <ins> 8.3. </ins> It is sometimes beneficial to deprioritize the transmission of one connection over others, knowing that doing so introduces a certain
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
text: textual value makes the prioritization scheme extensible; see the discussion below. <del> 9. </del> <ins> 10. TBD 11. </ins> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864:
Code change:
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.

Related discussion:
text: This document <del> 10.  References </del> <ins> 12.  References </ins> <del> 10.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Code change:
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.

Related discussion:
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> <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?
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
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.