jiebi/TextFlow huggingface dataset:
Original text:
<del> Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications </del>  draft-ietf-httpbis-client-cert-field-latest Abstract

Reviewer comments:
"Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications" is kind of ridiculous looking. Change it to just "Client-Cert HTTP Header Field" and move the rest to the abstract, if it doesn't already say as much.
shorter is better

Revised text:
 <ins> Client-Cert HTTP Header Field </ins> draft-ietf-httpbis-client-cert-field-latest Abstract
Original text:
Other deployments that meet the requirements set forth herein are also possible. <del> 4. </del>  The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core.

Reviewer comments:
Document what needs to happen for compression. The Client-Cert field will be largely constant for the same client, so it might be a good candidate for compression. However, with requests through the TTRP potentially coming from multiple clients, the connection to the origin server might get different values over time. Document what needs to happen here: either very large dynamic tables with certificates in them, or no compression for the field and larger requests. You also need to consider the effect on the protocol of very large header blocks. Both HTTP/2 and HTTP/3 have soft limits on the size of header blocks that this might exceed. Servers need to be provisioned to allow for large certificates. cc NAME
Thanks for the feedback Martin. I've read through RFC7541 and some of RFC7540 and I'm honestly still unsure what this draft can or should say about compression. As I understand it, the size of the dynamic table is established between the peers (dynamic table size update and SETTINGSHEADERTABLE_SIZE) of the connection. And the TTRP would decide whether or not to add client certs to the table. Undoubtedly there's a trade off between large dynamic table with certs and no compression for the field with larger requests. But I don't know what's "better" and imagine it will depend on the specifics of the deployment. Although I guess continually adding and evicting certs on a small table would be the worst of both. Are you looking to have that trade off described in something like an implementation/deployment considerations? Or something more or different? And if so, are there some specifics you can suggest or propose? WRT limits and large headers, URL has "A server that receives a request with a Client-Cert header value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of [RFC6585]." Is that wrong? Or insufficient? Or is this another implementation/deployment considerations thing where the draft should mention to readers that they might need to adjust some settings around maxim header sizes? Or something else?
Roughly, I think you could say something like
I think the issue is somewhat different. H2/H3 allow implementations to advertise a limit on the sum of the size of all headers received. If an intermediary and a backend advertise the same value, but the intermediary is adding huge headers, it's possible that a request that the client sent was within the limit, but the request sent by the intermediary to the server will be too large.
There's also some background in that might help explain the issue.
There are two things here really. Alan is concerned about header block size. Mark about compression efficiency. Both are worth mentioning.

Revised text:
Other deployments that meet the requirements set forth herein are also possible.  <ins> 5. </ins> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core.
Original text:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <del> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </del>  4.

Reviewer comments:
Remove "which" from a clause where it did not belong, as per feedback from Vijay Gurbani

Revised text:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.  <ins> If a server advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </ins> 4.
Original text:
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests.  3. 3.1.

Reviewer comments:
Attempt to cover client-cert and caching interactions per mnot's guidance in issue
Thanks Mark, accepted all your suggested changes
Origin servers might select a response based upon the value of the request header. This might impact caches in these situations: When an intermediary that's generating also has a cache When an intermediary between the generator of and the origin has a cache (e.g., as part of a CDN hierarchy or a server-side reverse proxy) When the client on the other side of the TLS connection has a cache (e.g., the browser or other user agent) and the UA's use of client certs varies (e.g., different certs are used, or no cert is used) Some guidance about this is probably necessary. In cases (1) and (2), it's just a matter of adding to all responses for an access-controlled resource. (3) is more subtle, because the browser/UA doesn't see the client cert in the request, since it's generated downstream. From its perspective, will always select a non-existent header field, and so it'll match whatever the certificate used actually is. The most straightforward thing to do for (3) is to advise that an intermediary generating MUST/SHOULD transform on responses (when it occurs) to . There need to be some detail work around how this should happen, to make sure that parsing corner cases are caught.
Thanks NAME and apologies that I somehow missed seeing this issue when you initially submitted it. I think I can put together a bit of text with guidance along the lines of your suggestions. Is it okay or preferred to use vs. ? , which isn't a standard I know but it does show up near the top of search results. And on trying to educate myself more I found that says 'A proxy MUST NOT generate a Vary field with a "" value.' I think RFC 7231 means proxy only in the forward proxy notion of proxy so it's okay for a reverse proxy / gateway. And draft-ietf-httpbis-semantics-19 has a more explicit definition of proxy as such. But it did give me pause.
Ignore MDN, it's often wrong (will file a PR there when I get a chance). is the most semantically correct, but making it uncacheable works too.
Thanks Mark. I took a pass at this with PR
Looks pretty good, a couple of nits

Revised text:
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled), the response MUST either be uncacheable (e.g., by sending "Cache- Control: no-store") or be designated for selective reuse only for subsequent requests with the same "Client-Cert" header value by sending a "Vary: Client-Cert" response header.  If a TTRP encounters a response with a "client-cert" field name in the "Vary" header field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". </ins> 3. 3.1.
Original text:
messages during the handshake and for the server to verify the CertificateVerify and Finished messages.  2. This document designates the following headers, defined further in

Reviewer comments:
painful words in an attempt to explain renegotiation's applicability with client-cert header to
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.

Revised text:
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC7230 where the server decides whether to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. </ins> 2. This document designates the following headers, defined further in
Original text:
5. <del> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core. </del> 

Reviewer comments:
fill out client-cert's IANA Considerations with HTTP field name registrations to
NAME wrote: http-core. This should be pretty simple to add, but for the purposes of having a clean PR pulling out the TODOs, I'm moving it to an issue for now anyway.
URL points to draft-ietf-httpbis-semantics for this

Revised text:
5.  <ins> 5.1. Please register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by I-D.ietf-httpbis- semantics: Field name: Client-Cert Status: permanent Specification document: headers of [this document] Field name: Client-Cert-Chain Status: permanent Specification document: headers of [this document] </ins>
Original text:
This document uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 with the list rule extension defined in RFC7230, Appendix B. <del> It includes by reference the DIGIT rule from RFC5234; the OWS, field- name and quoted-string rules from RFC7230; and the parameter rule from RFC7231. </del>  2.

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
This document uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 with the list rule extension defined in RFC7230, Appendix B.  <ins> It includes by reference the DIGIT rule from RFC5234 and the OWS and field-name rules from RFC7230. </ins> 2.
Original text:
received hints from the client.  When doing so, and if the resource is cacheable, the server MUST also emit a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis- <del> key), to indicate which hints were used and whether the selected response is appropriate for a later request. </del>  Further, depending on the used hint, the server can emit additional response header fields to confirm the property of the response, such

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
received hints from the client.  When doing so, and if the resource is cacheable, the server MUST also emit a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-  <ins> key), to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Further, depending on the used hint, the server can emit additional response header fields to confirm the property of the response, such
Original text:
For example: <del> When a client receives Accept-CH, it SHOULD append the Client Hint header fields that match the advertised field-values.  For example, based on Accept-CH example above, the client would append DPR, Width, Viewport-Width, and Downlink header fields to all subsequent requests. </del>  2.2.2. When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to emit a <del> Vary response header field (RFC7234) to indicate which hints were used and whether the selected response is appropriate for a later request. </del>  Above example indicates that the cache key needs to include the DPR header field.

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
For example:  <ins> When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it SHOULD append the Client-Hint header fields that match the advertised field-values to the header list of all subsequent requests.  For example, based on Accept-CH example above, a user agent could append DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated by the page constructed from the response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </ins> 2.2.2. When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to emit a  <ins> Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Above example indicates that the cache key needs to include the DPR header field.
Original text:
The "Width" request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image).  The provided physical px value is a number rounded to the <del> largest smallest following integer (i.e. ceiling value). </del>  If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
The "Width" request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image).  The provided physical px value is a number rounded to the  <ins> smallest following integer (i.e. ceiling value). </ins> If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field
Original text:
The "Viewport-Width" request header field is a number that indicates the layout viewport width in CSS px.  The provided CSS px value is a <del> number rounded to the largest smallest following integer (i.e. ceiling value). </del>  If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
The "Viewport-Width" request header field is a number that indicates the layout viewport width in CSS px.  The provided CSS px value is a  <ins> number rounded to the smallest following integer (i.e. ceiling value). </ins> If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.
Original text:
7. <del> The "Save-Data" request header field is a token that indicates client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </del>  This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode

Reviewer comments:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Revised text:
7.  <ins> The "Save-Data" request header field consists of one or more tokens that indicate client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode
Original text:
CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately.  A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string:

Reviewer comments:
~~
Thanks! This Lgtm but I'll let Steven take a look too
This looks to me as well, thanks!
UAs should not decode any URL-encoded (or otherwise encoded) characters while storing a cookie, e.g. a cookie such as should not be interpreted as a cookie. I landed some WPTs for this in URL Chrome, Edge, Firefox, and Safari do the right thing. I think this could just be a clarifying note in the parsing algorithm section.
I'll take this one
Let's make sure we are consistent for names and attributes.

Revised text:
CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. <ins> NOTE: The set-cookie-string may contain octet sequences that appear percent-encoded as per Section 2.1 of RFC3986.  However, a user agent MUST NOT decode these sequences and instead parse the individual octets as specified in this algorithm. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string:
Original text:
An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in <del> RFC8941 on a Dictionary containing only that item. </del>  Each parameterized key for a given field MUST NOT appear more than once in the signature input.  Parameterized keys MAY appear in any

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in  <ins> RFC8941 on the member value and its parameters, without the dictionary key. </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature input.  Parameterized keys MAY appear in any
Original text:
component identifiers of this field, presented using the signature input string format discussed in create-sig-input:  2.2. In addition to HTTP fields, there are a number of different

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
component identifiers of this field, presented using the signature input string format discussed in create-sig-input: <ins> Note that the value for "key="c"" has been re-serialized. </ins> 2.2. In addition to HTTP fields, there are a number of different
Original text:
This would result in the following unsigned response message: <del> The server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response.  The signature input string for this example is: </del>  The signed response message is:

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
This would result in the following unsigned response message:  <ins> To cryptographically link the response to the request, the server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response. The signature input string for this example is: </ins> The signed response message is:
Original text:
long enough to validate the signature of the response that uses this component identifier.  The "@request-response" component identifier MUST NOT be used in a request message.

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
long enough to validate the signature of the response that uses this component identifier. <ins> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. </ins> The "@request-response" component identifier MUST NOT be used in a request message.
Original text:
produce an error and not create an input string.  Such situations are included but not limited to: <del> The signer or verifier does not understand the component </del>  identifier. The component identifier identifies a field that is not present in the message or whose value is malformed. The component identifier indicates that a structured field <del> serialization is used, but the field in question is known to not be a structured field or the type of structured field is not known to the verifier. </del>  The component identifier is a dictionary member identifier that references a field that is not present in the message, is not a

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
produce an error and not create an input string.  Such situations are included but not limited to:  <ins> The signer or verifier does not understand the derived component </ins> identifier. The component identifier identifies a field that is not present in the message or whose value is malformed. The component identifier indicates that a structured field  <ins> serialization is used (via the "sf" parameter), but the field in question is known to not be a structured field or the type of structured field is not known to the implementation. </ins> The component identifier is a dictionary member identifier that references a field that is not present in the message, is not a