jiebi/CodeConvo huggingface dataset:
Code change:
add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need. If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)

Related discussion:
text: is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. <ins> Every digest-algorithm defines its computation procedure and encoding output.  Unless specified otherwise, comparison of encoded output is case-sensitive. </ins> The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields:
Code change:
add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need. If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)

Related discussion:
text: This memo sets this specification to be the establishing document for the HTTP Digest Algorithm Values [4] registry. <ins> IANA is asked to update the "Reference" for this registry to refer this document and to inizialize the registry with the tokens defined in algorithms. This registry uses the Specification Required policy (Section 4.6 of RFC8126). </ins> 13.2. This memo adds the "contentMD5" token in the HTTP Digest Algorithm
Code change:
This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.

Related discussion:
text: 2. A Targeted Cache-Control Header Field (hereafter, "targeted field") <del> is a HTTP response header field that has the same syntax and semantics as the Cache-Control response header field I-D.ietf- httpbis-cache, Section 5.2.  However, it has a distinct field name that indicates the target for its directives. </del> <ins> is a HTTP response header field that has the same semantics as the Cache-Control response header field (HTTP-CACHING, Section 5.2). However, it has a distinct field name that indicates the target for its directives. </ins> For example:
Code change:
This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.

Related discussion:
text: Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid and non-empty, a cache <del> falls back to other cache control mechanisms as required by HTTP I- D.ietf-httpbis-cache. </del> <ins> falls back to other cache control mechanisms as required by HTTP HTTP-CACHING. </ins> Targeted fields that are not on a cache's target list MUST NOT change that cache's behaviour, and MUST be passed through.
Code change:
This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.

Related discussion:
text: 4. Please register the following entry in the Hypertext Transfer <del> Protocol (HTTP) Field Name Registry defined by I-D.ietf-httpbis- semantics: </del> <ins> Protocol (HTTP) Field Name Registry defined by HTTP: </ins> Field Name: CDN-Cache-Control
Code change:
This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.

Related discussion:
text: 5. <del> The security considerations of HTTP caching I-D.ietf-httpbis-cache apply. </del> <ins> The security considerations of HTTP caching HTTP-CACHING apply. </ins> The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different
Code change:
The "Weak Integrity" section correctly notes that non-secure cookies can be set by network attackers, and will be sent to secure origins. This commit notes that the prefix is a mitigation against that attack.
NAME WDYT?
LGTM, thanks!

Related discussion:
text: uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and <del> signing the contents of their cookies.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </del> <ins> signing the contents of their cookies, or by naming the cookie with the "__Secure-" prefix.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </ins> Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies.  Once the user agent
Code change:
Fully editorial; "Application-Layer Protocol Negotiation" instead of "Application Layer Protocol Negotiation". URL
This fills me with joy

Related discussion:
text: Formally, an alternative service is identified by the combination of: <del> An Application Layer Protocol Negotiation (ALPN) protocol name, as </del> <ins> An Application-Layer Protocol Negotiation (ALPN) protocol name, as </ins> per A host, as per
Code change:
To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.

Related discussion:
text: RFC6455 over a single stream of an HTTP/2 connection.  It defines an Extended CONNECT method which specifies a new ":protocol" pseudo header field and new semantics for the ":path" and ":authority" <del> pseudo header fields.  It also defines a new HTTP/2 SETTING sent by a </del> <ins> pseudo header fields.  It also defines a new HTTP/2 setting sent by a </ins> server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection
Code change:
To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.

Related discussion:
text: FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3) <del> The semantics of the headers and SETTING are identical to those in </del> <ins> The semantics of the headers and setting are identical to those in </ins> HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in
Code change:
Tweak the phrasing of the abstract to make it a bit more clear that the document is adapting the mechanism not defining a mechanism.
There's nothing wrong with them per-se but in the space of 2 paragraphs the doc says This document describes the mechanism for HTTP/3. Appendix A.3 of [HTTP3] describes the required updates for HTTP/2 settings to be used with HTTP/3. So is it a new mechanism, a setting update, a new setting, or what?
Good point! That is a bit awkward. Check out and let me know what you think?

Related discussion:
text: Abstract The mechanism for running the WebSocket Protocol over a single stream <del> of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered.  This document describes the mechanism for HTTP/3. </del> <ins> of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP version-specific details need to be specified.  This document describes how the mechanism is adapted for HTTP/3. </ins> Note to Readers
Code change:
RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.

Related discussion:
text: The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are expected to use an alternative, such as the scheme defined in this specification. <del> The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first </ins> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR.
Code change:
RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.

Related discussion:
text: client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame). When the client receives the first SETTINGS frame that contains the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </ins> 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
Code change:
RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.

Related discussion:
text: The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that <del> receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </del> <ins> receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted
Code change:
RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.

Related discussion:
text: This specification registers the following entry in the HTTP/2 Settings registry established by HTTP2: <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES </ins> 0x9
Code change:
This sentence in the abstract might be relevant for those who are caught up in the way that h2 originally signaled priorities, but for those who will read this document later, it adds nothing. It's a distraction. Stick to what the document does rather than what it doesn't do.
I agree, thanks for the PR

Related discussion:
text: Abstract This document describes a scheme for prioritizing HTTP responses. <del> This scheme expresses the priority of each HTTP response using absolute values, rather than as a relative relationship between a group of HTTP responses. </del> This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing the responses.  These