jiebi/CodeConvo huggingface dataset:
Code change:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Related discussion:
text: providing those responses in parallel would be more helpful to the client than delivering the responses one by one. <del> There is no benefit in providing multiple responses with their incremental parameters set to false in parallel, as the client is not going to process those responses incrementally.  Serving non- incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del> <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
Code change:
A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.

Related discussion:
text: the Priority request header field set to "u=7" (background).  Then, when the user navigates to a page which references the new JavaScript file, while the prefetch is in progress, the browser would send a <del> reprioritization frame with the priority field value set to "u=0" (prerequisite). </del> <ins> reprioritization frame with the priority field value set to "u=0". </ins> In HTTP/2 and HTTP/3, after a request message is sent on a stream, the stream transitions to a state that prevents the client from
Code change:
Moves Digest Algorithms down
I verified the formatting here URL
This looks good but note the similar comment I made elsewhere about the trailing spaces after colons e.g. we need or else the formatting seems to get screwed up

Related discussion:
text: Response: <ins> 2.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 2.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. </ins> 3. <ins> The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 4. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are 5. </ins> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters may be supplied.
Code change:
Moves Digest Algorithms down
I verified the formatting here URL
This looks good but note the similar comment I made elsewhere about the trailing spaces after colons e.g. we need or else the formatting seems to get screwed up

Related discussion:
text: MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding. <del> 3.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 3.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. 4. The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 5. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are </del> 6. POST and PATCH requests may appear to convey partial representations
Code change:
This is a simple editorial change of the "changes" section, to add the latest PRs.
Landing as this change is not substantive

Related discussion:
text: 7.11. <del> PR 1072: LC feedback from Julian Reschke </del> <ins> PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. </ins> 8.  References
Code change:
Non substantive change to improve the list's style, after feedback on URL
Landing, as this is non-substantive

Related discussion:
text: Such features SHOULD take into account the following aspects of the information exposed: <del> Exposing highly granular data can be used to help identify users across multiple requests to different origins.  Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </del> <ins> Entropy - Exposing highly granular data can be used to help identify users across multiple requests to different origins. Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. Sensitivity - The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. Change over time - The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </ins> Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g.
Code change:
Apparently the removal of one appendix now has moved all remaining appendics into the main section. They need to be moved back.
LGTM! Thanks for catching that :)

Related discussion:
text: Specification document(s): accept-ch of this document Related information: for Client Hints <del> 7. </del> <ins> 7.  References </ins> <del> 7.1. Issue 168 (make Save-Data extensible) updated ABNF. Issue 163 (CH review feedback) editorial feedback from httpwg list. Issue 153 (NetInfo API citation) added normative reference. 7.2. Issue 200: Moved Key reference to informative. Issue 215: Extended passive fingerprinting and mitigation considerations. Changed document status to experimental. 7.3. Issue 239: Updated reference to CR-css-values-3 Issue 240: Updated reference for Network Information API Issue 241: Consistency in IANA considerations Issue 250: Clarified Accept-CH 7.4. Issue 284: Extended guidance for Accept-CH Issue 308: Editorial cleanup Issue 306: Define Accept-CH-Lifetime 7.5. Issue 361: Removed Downlink Issue 361: Moved Key to appendix, plus other editorial feedback 7.6. Issue 372: Scoped CH opt-in and delivery to secure transports Issue 373: Bind CH opt-in to origin 7.7. Issue 524: Save-Data is now defined by NetInfo spec, dropping PR 775: Removed specific features to be defined in other specifications 7.8. Issue 761: Clarified that the defined headers are response headers. Issue 730: Replaced Key reference with Variants. Issue 700: Replaced ABNF with structured headers. PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 7.9. PR 985: Describe the bytesize cost of hints. PR 776: Add Sec- and CH- prefix considerations. PR 1001: Clear CH persistence when cookies are cleared. 7.10. PR 1064: Fix merge issues with "cost of sending hints". 7.11. PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references. PR 1132: Remove nested list. 8.  References 8.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Code change:
"validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL

Related discussion:
text: in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. <del> The definition "validator" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis-semantics. </del> <ins> The definition "validator fields" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </ins> 2.
Code change:
"validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL

Related discussion:
text: request and response. The resource is specified by the effective request URI and any <del> "validator" contained in the message. </del> <ins> "validator field" contained in the message. </ins> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not-
Code change:
Nameless cookies serialize as . Valueless cookies serialize as . No, this isn't what we would have chosen if we were designing cookies from scratch, but it's Chromium and Firefox's shipping behavior, and it's reasonable to just accept. This specification change is covered by 0021 and 0022 in the WPT repository (see URL). Closes URL
WDYT, NAME / NAME ?
Step 4 says: However looking at WPT tests (for example [1] / [2]) I can see that when we have (empty name with value ) the expectation is to have back, so perhaps these instructions should include a special case when the cookie name is empty. [1] URL [2] URL
Minor suggestion, OK for me either way.

Related discussion:
text: Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order: <del> Output the cookie's name, the %x3D ("=") character, and the cookie's value. </del> <ins> If the cookies' name is not empty, output the cookie's name followed by the %x3D ("=") character. If the cookies' value is not empty, output the cookie's value. </ins> If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").
Code change:
The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .

Related discussion:
text: http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is not set, and the scheme </del> <ins> If the cookie's secure-only-flag is false, and the scheme </ins> component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following
Code change:
The 'secure-only-flag' is never "not set". It is either "true" or "false". This patch fixes two places where we should have been checking for falsity. Closes URL
NAME / NAME WDYT?
Good. I should have sent a PR. :-)
URL Step 8 says: But then Step 12 says: It's impossible to reach step 12 with the not set because it's always set in step 8. I believe a better wording would be .

Related discussion:
text: Expired cookies. <del> Cookies whose secure-only-flag is not set, and which share a domain field with more than a predetermined number of other cookies. </del> <ins> Cookies whose secure-only-flag is false, and which share a domain field with more than a predetermined number of other cookies. </ins> Cookies that share a domain field with more than a predetermined number of other cookies.
Code change:
Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!

Related discussion:
text: This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle <del> HTTP header and trailer fields, known as "Structured Fields", or "Structured Headers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </del> <ins> HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </ins> Note to Readers
Code change:
Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!

Related discussion:
text: Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a <del> Structured Field (only in the trailer section), or a Structured </del> <ins> Structured Trailer (only in the trailer section), or a Structured </ins> Field (both). Specify the type of the field value; either List (list),
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: Clients and servers that will accept requests for HTTP-layer certificate authentication indicate this using the HTTP/2 <del> "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, the value is non-zero. </del> <ins> "SETTINGS_HTTP_CLIENT_CERT_AUTH" (0xSETTING-TBD1) and "SETTINGS_HTTP_SERVER_CERT_AUTH" (0xSETTING-TBD2) settings. The initial value for both settings is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, one or both of the values is non-zero.  "SETTINGS_HTTP_CLIENT_CERT_AUTH" indicates that servers can use certificates for client authentication, while "SETTINGS_HTTP_SERVER_CERT_AUTH" indicates that servers are able to offer additional certificates to demonstrate control over other origin hostnames. </ins> In order to ensure that the TLS connection is direct to the server, rather than via a TLS-terminating proxy, each side will separately <del> compute and confirm the value of this setting.  The setting is derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </del> <ins> compute and confirm the value of these settings.  The setting values are derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </ins> The exporter is constructed with the following input:
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: Context: Empty <del> Length: Four bytes </del> <ins> Length: Eight bytes The value of the exporter is split into two four-byte values.  The first four bytes are used for the "SETTINGS_HTTP_CLIENT_CERT_AUTH" value, while the following four bytes are used for the "SETTINGS_HTTP_SERVER_CERT_AUTH" value. </ins> <del> The resulting exporter is converted to a setting value as: </del> <ins> Each is converted to a setting value as: </ins> That is, the most significant bit will always be set, regardless of the value of the exporter.  Each endpoint will compute the expected <del> value from their peer.  If the setting is not received, or if the </del> <ins> values from their peer.  If the setting is not received, or if the </ins> value received is not the expected value, the frames defined in this <del> document SHOULD NOT be sent. </del> <ins> document SHOULD NOT be sent in the indicated direction. </ins> 2.2. When both peers have advertised support for HTTP-layer certificates <del> as in setting, either party can supply additional certificates into the connection at any time.  This means that clients or servers which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </del> <ins> in a given direction as in setting, the indicated endpoint can supply additional certificates into the connection at any time.  That is, if both endpoints have sent "SETTINGS_HTTP_SERVER_CERT_AUTH" and validated the value received from the peer, the server may send certificates.  If both endpoints have sent "SETTINGS_HTTP_CLIENT_CERT_AUTH" and validated the value received from the peer, the client may send certificates. Implementations which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </ins> Certificates supplied by servers can be considered by clients without further action by the server.  A server SHOULD NOT send certificates