jiebi/TextFlow huggingface dataset:
Original text:
specifies a desired certificate.  This describes the certificate the sender wishes to have presented. <del> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del>  The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero.  A "CERTIFICATE_REQUEST" frame received on any other stream MUST be

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
specifies a desired certificate.  This describes the certificate the sender wishes to have presented.  <ins> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero.  A "CERTIFICATE_REQUEST" frame received on any other stream MUST be
Original text:
This draft adds entries in three registries. <del> The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in iana- setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </del>  7.1. <del> The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 Settings" registry established in RFC7540. SETTINGS_HTTP_CERT_AUTH 0xSETTING-TBD 0 This document. </del>  7.2.

Reviewer comments:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Revised text:
This draft adds entries in three registries.  <ins> The feature negotiation settings is registered in iana-setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </ins> 7.1.  <ins> The SETTINGS_HTTP_CLIENT_CERT_AUTH and SETTINGS_HTTP_SERVER_CERT_AUTH settings are registered in the "HTTP/2 Settings" registry established in RFC7540. </ins> 7.2.
Original text:
Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any).  Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. Clients MUST NOT accept any end-entity certificate from an exported

Reviewer comments:
though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.

Revised text:
Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any). <ins> If the authenticator cannot be validated, this SHOULD be treated as a connection error of type "CERTIFICATE_UNREADABLE". </ins> Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. Clients MUST NOT accept any end-entity certificate from an exported
Original text:
If a client receives a "PUSH_PROMISE" referencing an origin for which it has not yet received the server's certificate, this is a stream <del> error (see section 8.2 of RFC7540).  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </del>  2.3.2.

Reviewer comments:
Automatic use of client-proffered certificates was removed a while back; clients can indicate which certificate (if any) they want the server to consider by sending a frame with the flag set. There was text talking about automatic use of the server-proffered certificates, but there wasn't corresponding text disallowing that behavior for client certificates, simply the absence of permission. This PR forbids considering "available" certificates until the client indicates which certificate to use.
The secondary certificates draft leaves the authentication state of exchanges like the following unclear: In stream 1, the client is unambiguously using certificate A in the request to . Is it also using it for ? If the client believes the answer is no, while the server believes the answer is yes, secondary certificates introduces a . Some examples to consider: HTTP/2 cross-name pooling means one connection may service multiple origins. The client may choose to use a client certificate with some origins but not others. The web platform makes both anonymous and credentialed requests (see CORS). Keeping those straight is critical to avoid CSRF attacks. For now, browsers do not pool them due to various problematic connection-level auth mechanisms in HTTP/1.1, but there is discussion on relaxing this for the vast majority of connections that don't use these. This puts a heavier dependency on protocols getting these kinds of details right. This is especially important to make unambiguous because the original renegotiation-based hack for reactive client auth did rely on ambient authority. Once you renegotiated with a certificate, the unwritten interpretation was that all subsequent requests on this connection pick up the certificate. A server implementation may then be tempted to apply a similar logic to client certificates. The spec needs a MUST-level requirement not to do this, and make it clear that this is a server security vulnerability. Instead, client wishing to approximate the original renegotiation-based hack would send proactive frames on subsequent credentialed requests. This is especially important for HTTP/2, where there is both larger scope of pooling from cross-name bits and where multiplexing means we requests overlap temporally.

Revised text:
If a client receives a "PUSH_PROMISE" referencing an origin for which it has not yet received the server's certificate, this is a stream  <ins> error on the push stream; see section 8.2 of RFC7540.  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </ins> 2.3.2.
Original text:
Some algorithms, although registered, have since been found vulnerable: the MD5 algorithm MUST NOT be used due to collision <del> attacks CMU-836068 and the SHA algorithm is NOT RECOMMENDED due to collision attacks IACR-2019-459. </del> 

Reviewer comments:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Revised text:
Some algorithms, although registered, have since been found vulnerable: the MD5 algorithm MUST NOT be used due to collision  <ins> attacks CMU-836068 and the SHA algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>
Original text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  The <del> SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. </del>  Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: obsoleted </del> 

Reviewer comments:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Revised text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  The  <ins> SHA algorithm MUST NOT be used as it's now vulnerable to collision attacks IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.  <ins> Status: deprecated </ins>
Original text:
However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to <del> collisions attacks, so MD5 MUST NOT be used and SHA-1 is NOT RECOMMENDED for use with "Digest". </del>  11.3.

Reviewer comments:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Revised text:
However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to  <ins> collisions attacks, so they MUST NOT be used with "Digest". </ins> 11.3.
Original text:
9.2.  As there is no content coding applied, the "sha-256" and the "id-sha- <del> 256" digest-values are the same. </del>  Request:

Reviewer comments:
adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256

Revised text:
9.2. <ins> Requests without a payload body can still send a Digest field applying the digest algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha-  <ins> 256" digest-values in the response are the same. </ins> Request:
Original text:
A "Digest" field using NOT RECOMMENDED digest-algorithms SHOULD NOT be used in signatures.  11.7. When used in trailers, the receiver gets the digest value after the

Reviewer comments:
adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256

Revised text:
A "Digest" field using NOT RECOMMENDED digest-algorithms SHOULD NOT be used in signatures. <ins> Using signatures to protect the Digest of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </ins> 11.7. When used in trailers, the receiver gets the digest value after the
Original text:
1.2. <del> The concept of "selected representation" defined in Section 6 of I- D.ietf-httpbis-semantics makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with I-D.ietf-httpbis- semantics concepts. </del>  Basing "Digest" on the selected representation makes it straightforward to apply it to use-cases where the transferred data does require some sort of manipulation to be considered a representation, or conveys a partial representation of a resource eg. <del> Range Requests (see Section 8.3 of I-D.ietf-httpbis-semantics). </del>  Changes are semantically compatible with existing implementations and better cover both the request and response cases.

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
1.2.  <ins> The concept of "selected representation" defined in Section 6 of SEMANTICS makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with SEMANTICS concepts. </ins> Basing "Digest" on the selected representation makes it straightforward to apply it to use-cases where the transferred data does require some sort of manipulation to be considered a representation, or conveys a partial representation of a resource eg.  <ins> Range Requests (see Section 8.3 of SEMANTICS). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.
Original text:
different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 6.1.2 of I-D.ietf-httpbis-semantics) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </del>  1.3.

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
different digest values. To allow both parties to exchange a Digest of a representation with  <ins> no content codings (see Section 6.1.2 of SEMANTICS) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </ins> 1.3.
Original text:
This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405 along with the "#rule" extension defined in Section 4 of <del> I-D.ietf-httpbis-semantics. </del>  The definitions "representation", "selected representation", "representation data", "representation metadata", and "payload body" <del> in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. </del>  The definition "validator fields" in this document is to be <del> interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </del>  2. The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of the payload body and message body.  It uses the representation data <del> (see Section 6.1 of I-D.ietf-httpbis-semantics), that can be fully or partially contained in the message body, or not contained at all: </del>  This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405 along with the "#rule" extension defined in Section 4 of  <ins> SEMANTICS. </ins> The definitions "representation", "selected representation", "representation data", "representation metadata", and "payload body"  <ins> in this document are to be interpreted as described in SEMANTICS. </ins> The definition "validator fields" in this document is to be  <ins> interpreted as described in Section 10.2 of SEMANTICS. </ins> 2. The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of the payload body and message body.  It uses the representation data  <ins> (see Section 6.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range
Original text:
The resource is specified by the effective request URI and any "validator field" contained in the message. <del> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not- request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </del>  A Digest field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
The resource is specified by the effective request URI and any "validator field" contained in the message.  <ins> The relationship between Content-Location (see Section 6.2.5 of SEMANTICS) and Digest is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </ins> A Digest field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
Original text:
computation.  For some algorithms, one or more parameters can be supplied. <del> The BNF for "parameter" is defined in Section 4.4.1.4 of I-D.ietf- httpbis-semantics.  All digest-algorithm values are case-insensitive. </del>  The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
computation.  For some algorithms, one or more parameters can be supplied.  <ins> The BNF for "parameter" is defined in Section 4.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed
Original text:
(see acting-on-resources). The representation enclosed in the response refers to the resource <del> identified by "Content-Location" (see I-D.ietf-httpbis-semantics Section 6.3.2). </del>  "Digest" is thus computed on the enclosed representation.

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
(see acting-on-resources). The representation enclosed in the response refers to the resource  <ins> identified by "Content-Location" (see SEMANTICS Section 6.3.2). </ins> "Digest" is thus computed on the enclosed representation.
Original text:
12.10. This section registers the "Want-Digest" field in the "Hypertext <del> Transfer Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis- semantics. </del>  Field name: "Want-Digest"

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
12.10. This section registers the "Want-Digest" field in the "Hypertext  <ins> Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Want-Digest"
Original text:
12.11. This section registers the "Digest" field in the "Hypertext Transfer <del> Protocol (HTTP) Field Name Registry" I-D.ietf-httpbis-semantics. </del>  Field name: "Digest"

Reviewer comments:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Revised text:
12.11. This section registers the "Digest" field in the "Hypertext Transfer  <ins> Protocol (HTTP) Field Name Registry" SEMANTICS. </ins> Field name: "Digest"