jiebi/TextFlow huggingface dataset:
Original text:
This memo sets this specification to be the establishing document for the HTTP Digest Algorithm Values [4] registry.  13.2. This memo adds the "contentMD5" token in the HTTP Digest Algorithm

Reviewer comments:
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 :)

Revised 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
Original 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>  For example:

Reviewer comments:
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.

Revised text:
2. A Targeted Cache-Control Header Field (hereafter, "targeted field")  <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:
Original 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>  Targeted fields that are not on a cache's target list MUST NOT change that cache's behaviour, and MUST be passed through.

Reviewer comments:
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.

Revised 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  <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.
Original 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>  Field Name: CDN-Cache-Control

Reviewer comments:
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.

Revised text:
4. Please register the following entry in the Hypertext Transfer  <ins> Protocol (HTTP) Field Name Registry defined by HTTP: </ins> Field Name: CDN-Cache-Control
Original text:
5. <del> The security considerations of HTTP caching I-D.ietf-httpbis-cache apply. </del>  The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different

Reviewer comments:
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.

Revised text:
5.  <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
Original 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>  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

Reviewer comments:
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!

Revised text:
uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and  <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
Original text:
Formally, an alternative service is identified by the combination of: <del> An Application Layer Protocol Negotiation (ALPN) protocol name, as </del>  per A host, as per

Reviewer comments:
Fully editorial; "Application-Layer Protocol Negotiation" instead of "Application Layer Protocol Negotiation". URL
This fills me with joy

Revised text:
Formally, an alternative service is identified by the combination of:  <ins> An Application-Layer Protocol Negotiation (ALPN) protocol name, as </ins> per A host, as per
Original 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>  server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection

Reviewer comments:
To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.

Revised 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"  <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
Original 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>  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

Reviewer comments:
To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.

Revised text:
FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3)  <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
Original 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>  Note to Readers

Reviewer comments:
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?

Revised text:
Abstract The mechanism for running the WebSocket Protocol over a single stream  <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
Original 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>  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>  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>  SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR.

Reviewer comments:
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.

Revised text:
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540).  <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.  <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  <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.
Original 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>  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

Reviewer comments:
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.

Revised 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  <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
Original 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>  Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted

Reviewer comments:
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.

Revised 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  <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
Original text:
This specification registers the following entry in the HTTP/2 Settings registry established by HTTP2: <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES </del>  0x9

Reviewer comments:
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.

Revised text:
This specification registers the following entry in the HTTP/2 Settings registry established by HTTP2:  <ins> SETTINGS_NO_RFC7540_PRIORITIES </ins> 0x9
Original 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

Reviewer comments:
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

Revised text:
Abstract This document describes a scheme for prioritizing HTTP responses.  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