jiebi/CodeConvo huggingface dataset:
Code change:
Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.

Related discussion:
text: 4.1.5. <del> Given a decimal_number as input_decimal, return an ASCII string </del> <ins> Given a decimal number as input_decimal, return an ASCII string </ins> suitable for use in a HTTP field value. <ins> If input_decimal is not a decimal number, fail serialisation. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialisation. </ins> Let output be an empty string. If input_decimal is less than (but not equal to) 0, append "-" to
Code change:
Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.

Related discussion:
text: Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". <del> If the number of characters appended in the previous step is greater than 12, fail serialisation. </del> Append "." to output. If input_decimal's fractional component is zero, append "0" to output. <del> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal </del> <ins> Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal </ins> digits) to output. <del> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </del> Return output. 4.1.6.
Code change:
Small editorial fix. I'm also not comfortable with "a integer", maybe remove "a"? Anyway that's a nitpick.
Thanks NAME
LGTM

Related discussion:
text: 3.3. <del> An item is can be a integer (integer), decimal (decimal), string </del> <ins> An item can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).
Code change:
NAME I'm just going to land this (as it's trivial), and roll an -05 today.
This should use a named section reference, no? Otherwise it can break again when section numbers change.
In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!

Related discussion:
text: Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described <del> in section 2.1), which is only a speedbump along the road to </del> <ins> in section 5.2.1), which is only a speedbump along the road to </ins> exploitation. Features like "<link rel='prerender'>" prerendering can be
Code change:
In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!

Related discussion:
text: Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described <del> in section 5.2.1), which is only a speedbump along the road to </del> <ins> in document-requests), which is only a speedbump along the road to </ins> exploitation. Features like "<link rel='prerender'>" prerendering can be
Code change:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Related discussion:
text: If more member_values remain in input_list: <del> Append a COMMA to output. </del> <ins> Append "," to output. </ins> Append a single SP to output.
Code change:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Related discussion:
text: If more members remain in input_dictionary: <del> Append a COMMA to output. </del> <ins> Append "," to output. </ins> Append a single SP to output.
Code change:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Related discussion:
text: If input_string is empty, return members. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del> <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.
Code change:
The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.

Related discussion:
text: If input_string is empty, return dictionary. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del> <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.
Code change:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Related discussion:
text: HTTP Client Hints <del> draft-ietf-httpbis-client-hints-08 </del> <ins> draft-ietf-httpbis-client-hints-10 </ins> Abstract
Code change:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Related discussion:
text: clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared. <del> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. 5.1. </del> <ins> 4.2. </ins> Deployment of new request headers requires several considerations:
Code change:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Related discussion:
text: Doing so makes them easier to identify programmatically (e.g., for stripping unrecognised hints from requests by privacy filters). <del> 5.2. </del> <ins> 4.3. </ins> A user agent that tracks access to active fingerprinting information SHOULD consider emission of Client Hints headers similarly to the way
Code change:
When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).

Related discussion:
text: and from those without.  This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use. <ins> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. </ins> 6. This document defines the "Accept-CH" HTTP response field, and
Code change:
We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!

Related discussion:
text: the server. An origin can use the Priority response header field to indicate its <del> view on how an HTTP response should be prioritized.  When forwarding an HTTP response with the Priority response header field, an intermediary can use the parameters being found in that response instead of those found in the request. </del> <ins> view on how an HTTP response should be prioritized.  An intermediary that forwards an HTTP response can use the parameters found in the Priority response header field, in combination with the client Priority request header field, as input to its prioritization process.  No guidance is provided for merging priorities, this is left as an implementation decision. </ins> Absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value.  This is
Code change:
We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!

Related discussion:
text: in which omission of a priority parameter implies the use of their default values (see #parameters). <del> For example, when the client sends an HTTP request with </del> <ins> As a non-normative example, when the client sends an HTTP request with </ins> and the origin responds with the intermediary might alter its understanding of the urgency from <del> "5" to "1", because the server-provided value overrides the value provided by the client.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </del> <ins> "5" to "1", because it prefers the server-provided value over the client's.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </ins> incremental("i") parameter. 7.
Code change:
cc: NAME
Thank you for the fix.
RFC8586 is very clear about other uses of : The current priority draft uses it to detect whether there upstream intermediaries, not loop detection. This should be removed.

Related discussion:
text: configuration, or by consulting if that request contains one of the following header fields: <del> CDN-Loop (RFC8586) </del> Forwarded, X-Forwarded-For (RFC7239) Via (RFC7230, Section 5.7.1)
Code change:
The intent here is to say that your requirements for trusting a secondary certificate should be at least as strict as for trusting additional names in the primary certificate.
Add text noting the DNS check / not-check guidance in RFCs 7540 and 8336, respectively. Explicitly side-step the issue by saying that if you would do a DNS lookup for a hostname in the primary cert, you MUST do the DNS check for a hostname in a secondary cert as well; if you would omit the DNS lookup for a hostname in the primary cert, you MAY omit the DNS check for a hostname in the secondary cert as well.

Related discussion:
text: than needing to subvert DNS or IP routing in order to use a compromised certificate, a malicious server now only needs a client to connect to _some_ HTTPS site under its control in order to present <del> the compromised certificate.  As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </del> <ins> the compromised certificate.  Clients SHOULD consult DNS for hostnames presented in secondary certificates if they would have done so for the same hostname if it were present in the primary certificate. As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </ins> One such means is the Required Domain certificate extension defined in {extension}. Clients MUST require that server certificates
Code change:
I believe that NAME comment on that issue is already covered by the following section on Denial of Service.
If a malicious server claims support for a variety of common hostnames for which it doesn't actually possess certificates, browser clients with a long-lived connection to the attacker will probe for certificates when the user attempts to access those sites. This allows the server to monitor user behavior during the lifetime of the connection, even without valid certificates. One obvious strategy is to probe everything "interesting" ASAP after the ORIGIN frame, but that obviously leaks what the client considers interesting, which is its own privacy leak. Note that a DNS lookup of claimed hostnames prior to requesting the cert prevents this attack. Should probably recommend that clients which omit the DNS lookup never solicit secondary server certificates, but probably don't need to mandate anything.
In addition to monitoring user behavior, depending on client behavior (do you race two connections? fallback on error?), the malicious server could also deny access to other hostname or degrade performance.

Related discussion:
text: send only the extensions that narrowly specify which certificates would be acceptable. <ins> Servers can also learn information about clients using this mechanism.  The hostnames a user agent finds interesting and retrieves certificates for might indicate origins the user has previously accessed. </ins> 6.3. Failure to provide a certificate for a stream after receiving
Code change:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Related discussion:
text: 3.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority. </del> <ins> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </ins> The value is encoded as an sh-integer.  The default value is 1.
Code change:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Related discussion:
text: way that is backwards compatible for peers that are unaware of the extended meaning. <ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range using an additional parameter.  Implementations that do not recognize the parameter can safely continue to use the less granular eight levels. Alternatively, the urgency can be augmented.  For example, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. </ins> 4. The Priority HTTP header field can appear in requests and responses.
Code change:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Related discussion:
text: 6. It is not always the case that the client has the best understanding <del> of how the HTTP responses deserve to be prioritized.  For example, use of an HTML document might depend heavily on one of the inline images.  Existence of such dependencies is typically best known to the server. </del> <ins> of how the HTTP responses deserve to be prioritized.  The server might have additional information that can be combined with the client's indicated priority in order to improve the prioritization of the response.  For example, use of an HTML document might depend heavily on one of the inline images; existence of such dependencies is typically best known to the server.  Or, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </ins> An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized.  An intermediary
Code change:
We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...

Related discussion:
text: textual value makes the prioritization scheme extensible; see the discussion below. <del> 8.2. One of the aims of this specification is to define a mechanism for merging client- and server-provided hints for prioritizing the responses.  For that to work, each urgency level needs to have a well-defined meaning.  As an example, a server can assign the highest precedence among the supplementary responses to an HTTP response carrying an icon, because the meaning of "u=2" is shared among the endpoints. This specification restricts itself to defining a minimum set of urgency levels in order to provide sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. However, that does not mean that the prioritization scheme would forever be stuck to the eight levels.  The design provides extensibility.  If deemed necessary, it would be possible to subdivide any of the eight urgency levels that are currently defined. Or, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. A server can combine the hints provided in the Priority header field with other information in order to improve the prioritization of responses.  For example, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </del> 9. This specification registers the following entry in the Permanent
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: 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 <del> intermediaries want to specify prioritizaton on a multiplexed HTTP </del> <ins> intermediaries want to specify prioritization on a multiplexed HTTP </ins> connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.
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: The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to <del> "1". </del> <ins> "true". </ins> 3.3.