jiebi/CodeConvo huggingface dataset:
Code change:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Related discussion:
text: server's disinterest in changing the client-provided value.  This is different from the logic being defined for the request header field, in which omission of a priority parameter implies the use of their <del> default values (see #parameters). </del> <ins> default values (see parameters). </ins> As a non-normative example, when the client sends an HTTP request <del> with </del> <ins> with the urgency parameter set to "5" and the incremental parameter set to "true" </ins> and the origin responds with the intermediary might alter its understanding of the urgency from "5" to "1", because it prefers the server-provided value over the <del> client's.  The incremental value continues to be "1", the value </del> <ins> client's.  The incremental value continues to be "true", the value </ins> specified by the client, as the server did not specify the incremental("i") parameter.
Code change:
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.

Related discussion:
text: In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the <del> priority of "u=1, i=?1" (i.e. round-robin) regardless of the value of </del> <ins> priority of "u=1, i" (i.e. round-robin) regardless of the value of </ins> the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients.
Code change:
This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.

Related discussion:
text: If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail serialisation. <del> If the first character of input_key is not lcalpha, fail </del> <ins> If the first character of input_key is not lcalpha or "*", fail </ins> serialisation. Let output be an empty string.
Code change:
This change to the key syntax allows dictionaries and parameters to use "" as a starting character for names, allowing keys like value mygoditsfullofstars*
LGTM. Do you want to add the change note, or shall I do that after merging?
BTW - would take a PR with an example key that looks like the last one above :)
In URL, NAME asks for as a dictionary member name. I think this just means adding it to valid start characters in key.

Related discussion:
text: Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value. <del> If the first character of input_string is not lcalpha, fail </del> <ins> If the first character of input_string is not lcalpha or "*", fail </ins> parsing. Let output_string be an empty string.
Code change:
NAME I was tired of the warnings of line too long, so I've reflowed a lot of the examples and also most of the text while I was at it. The Python code example was tricky, please pay attention to that as I may have mangled it.
LGTM

Related discussion:
text: Status: standard <del> Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content- Encoding: identity") Reference: RFC6234, RFC4648, this document. Status: standard </del> <ins> ID-SHA-256: : * Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content-Encoding: identity") * Reference: RFC6234, RFC4648, this document.  * Status: standard </ins> If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include
Code change:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

Related discussion:
text: example: Members whose value is Boolean true MUST omit that value when <del> serialised, unless it has Parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has Parameters: </del> <ins> serialised.  For example, here both "b" and "c" are true: </ins> Note that this requirement is only on serialisation; parsers are <del> still required to correctly handle the true value when it appears in Dictionary values. </del> <ins> still required to correctly handle the true Boolean value when it appears in Dictionary values. </ins> A Dictionary with a member whose value is an Inner List of tokens:
Code change:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

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 not Boolean true or parameters is not empty: </del> <ins> If member_value is Boolean true: Append the result of running Serializing Parameters (ser- params) with parameters to output. Otherwise: </ins> Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising 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> If more members remain in input_dictionary:
Code change:
Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.

Related discussion:
text: Let value be Boolean true. <del> Let parameters be an empty, ordered map. </del> <ins> Let parameters be the result of running Parsing Parameters parse-param with input_string. </ins> Let member be the tuple (value, parameters).
Code change:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Related discussion:
text: 2.1. <del> Clients control which Client Hints are sent in requests, based on their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </del> <ins> Clients choose what Client Hints to send in a request based on their default settings, user configuration, and server preferences expressed in "Accept-CH".  The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </ins> Implementers SHOULD be aware of the passive fingerprinting implications when implementing support for Client Hints, and follow
Code change:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Related discussion:
text: selected response and whether the selected response is appropriate for a later request. <del> Further, depending on the hint used, the server can generate additional response header fields to convey related values to aid client processing. </del> <ins> Furthermore, the server can generate additional response header fields (as specified by the hint or hints in use) that convey related values to aid client processing. </ins> 3.
Code change:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Related discussion:
text: 3.1. <del> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (Section 4.2.5.3 of HTML) indicate server support for particular hints indicated in its value. </del> <ins> The Accept-CH response header field indicates server support for the hints indicated in its value. </ins> Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-
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: interoperability. The rich flexibility of client-driven HTTP/2 prioritization tree <del> building is rarely exercised; experience shows that clients either choose a single model optimized for a web use case (and don't vary it) or do nothing at all.  But every client builds their prioritization tree in a different way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme, some favoring instead bespoke server-driven schemes based on heuristics and other hints, like the content type of <del> resources and the order in which requests arrive.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </del> <ins> resources and the request generation order.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </ins> The HTTP/2 scheme allows intermediaries to coalesce multiple client trees into a single tree that is used for a single upstream HTTP/2
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 client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD <del> stop sending PRIORITY_UPDATE frames, but MAY continue sending the Priority header field, as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del> <ins> stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2
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: room for future extensions.  Each key-value pair represents a priority parameter. <del> The Priority HTTP header field is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del> <ins> The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Headers Dictionary (STRUCTURED-HEADERS).