jiebi/TextFlow huggingface dataset:
Original text:
The details of this kind of profiling are the purview of the application and outside the scope of this specification, however some <del> additional considerations are discussed in security. </del>  2.

Reviewer comments:
Adds a citation in 1.4 for DIGEST and forward links to the security considerations sections for covered component selection and message body coverage.
Minor issue noted while reviewing. -13 does give a good overview of message content considerations, and mentions Content-Digest along with a citation to the digest headers draft. However, the earliest mention of Content-Digest is in section 1.4, and there are several examples through the text that use it. Simple fixup is to cite digest in section 1.4 too, and forward ref to 7.2.8 so anyone interested in this knows where to jump to.

Revised text:
The details of this kind of profiling are the purview of the application and outside the scope of this specification, however some  <ins> additional considerations are discussed in security.  In particular, when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in security-coverage and security-message- content. </ins> 2.
Original text:
The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field <del> value as defined in Section 5.5 of RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </del>  2.3.

Reviewer comments:
to
Currently, the references to HTTP semantics and to all HTTP versions are informative. While there are only two references to RFC9110, I find myself skeptical that someone would be able to implement it without knowing HTTP. We might consider making 9110 an normative reference, even if we think the individual pointers into it don't rise to that level.
You could normatively depend on the intermediary definitions in URL
Agreed about making HTTP semantics a normative reference.
Using and alining with 9110's intermediary definitions is likely worthwhile too. However, that's a larger effort that should maybe be considered separately?
I'm not too bothered about just changing labels between informative or normative. Thats easy to do and can be changed easily enough at later date. I think this draft actually does a good job of talking about the specialist case of a TTRP and we should keep that without too much meddling. But if the prose would benefit from shaking out a stronger sense of if implementations have normative requirements (directly or via references), I think this is a good ticket to track that against.
Thanks for the thoughts, Lucas. I'm inclined to not do much meddling.

Revised text:
The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field  <ins> value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </ins> 2.3.
Original text:
Abstract <del> This document defines HTTP extension header fields that allow a TLS </del>  terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner.

Reviewer comments:
and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM

Revised text:
Abstract  <ins> This document describes HTTP extension header fields that allow a TLS </ins> terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner.
Original text:
commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> This document aspires to standardize two HTTP header fields, "Client- Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client-Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic. While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </del>  certificate that was presented by the originating client in its connection to the TTRP.

Reviewer comments:
and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM

Revised text:
commonly occurring functionality could improve and simplify interoperability between independent implementations.  <ins> This document describes two HTTP header fields, "Client-Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client- Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </ins> certificate that was presented by the originating client in its connection to the TTRP.
Original text:
value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request.  2.3. In the context of a TLS terminating reverse proxy deployment, the

Reviewer comments:
It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.

Revised text:
value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. <ins> example-header in example has an example of the "Client-Cert" header field. </ins> 2.3. In the context of a TLS terminating reverse proxy deployment, the
Original text:
purposes, it might be advantageous to split lists into multiple instances.  2.4. This section outlines the applicable processing rules for a TLS

Reviewer comments:
It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.

Revised text:
purposes, it might be advantageous to split lists into multiple instances. <ins> example-chain-header in example has an example of the "Client-Cert- Chain" header field. </ins> 2.4. This section outlines the applicable processing rules for a TLS
Original text:
application requirements.  In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application <del> server.  A common way this information is conveyed in practice today is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </del>  interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what field names are used or are

Reviewer comments:
Intro para 3 has a chunk of text about fields not defined in this doc This could be condensed to say that the header fields in this document provide a standardized replacement for custom or proprietary fields that were known to be used prior to this document.
It is perhaps a bit long winded and admittedly not award winning literature. But I think it's useful context for the reader and prefer to keep it.
Right but in 20 years if the RFC says "a common practice today is using non-standard fields" it could read odd. Its clearer if this spec focuses on what it provides not what people came up with as custom solutions beforehand.
Thanks, looks good!

Revised text:
application requirements.  In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application  <ins> server.  At the time of writing, a common way this information is conveyed is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </ins> interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what field names are used or are
Original text:
3.1. <del> If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK HPACK or QPACK QPACK) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </del>  3.2.

Reviewer comments:
reword the header compression section with more consistent terms for the roles (to
LGTM modulo nit
This section talks about header compression and says Elsewhere in the document, you've used TTRP and Origin to identify the roles in play. I think it would be clearer to use them here. For instance, I might rewrite this as something like

Revised text:
3.1.  <ins> If the connection between the TTRP and origin is capable of field compression (e.g., HPACK HPACK or QPACK QPACK), and the TTRP multiplexes more than one client's requests into that connection, the size and variation of "Client-Cert" and "Client-Cert-Chain" field values can reduce compression efficiency significantly.  An origin could mitigate the efficiency loss by increasing the size of the dynamic table.  If the TTRP determines that the origin dynamic table is not sufficiently large, it may find it beneficial to always send the field value as a literal, rather than entering it into the table. </ins> 3.2.
Original text:
3.2. <del> A server in receipt of a larger header block than it is willing to </del>  handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to <del> allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </del>  3.3.

Reviewer comments:
Attempt to reword the 'Header Block Size' section to use more HTTP version neutral terms (for )
Is this a hangover from terminology changes elsewhere? URL says
Very possible that it's a hangover from terminology changes elsewhere. Very possible. But I'm not quite sure how to update it. HTTP/3 talks about the "size of the message header" (from your reference) while HTTP/2 talks about block size but now uses field block size URL rather than header block size URL How about the following though? Assuming I'm even adjusting the terminology you're suggesting needs adjusting. Message header seems more neutral and appropriate.
Thanks for the suggestion and PR. I think we're best off holding for NAME review since he had to do a similar renaming exercise for HTTP/3 and is an expert now
Makes sense. I, for one, would welcome such expertise.
URL Mike okayed it
Yes, this looks reasonable.

Revised text:
3.2.  <ins> A server in receipt of a larger message header than it is willing to </ins> handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to  <ins> allow for a larger maximum header size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header size (e.g.  HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </ins> 3.3.
Original text:
deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the "Client-Cert" and "Client-Cert- <del> Chain" header fields occurring only on that connection. Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server. Other deployments that meet the requirements set forth herein are also possible. </del>  5.

Reviewer comments:
h/t NAME
The security considerations pay some good attention to the concerns of the actors that might deal with the headers defined in client-certs. It crossed my mind that you could mention header protection mechanisms, like Signatures, as one way to harden things.
Yeah, Signatures could be mentioned in there as a possible additional measure.

Revised text:
deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the "Client-Cert" and "Client-Cert-  <ins> Chain" header fields occurring only on that connection.  I-D.ietf- httpbis-message-signatures gives one example of this with an application of HTTP Message Signatures.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server.  Other deployments that meet the requirements set forth herein are also possible. </ins> 5.
Original text:
1.2.  Phrases like TLS client certificate authentication or mutually- authenticated TLS are used throughout this document to refer to the process whereby, in addition to the normal TLS server authentication

Reviewer comments:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Revised text:
1.2. <ins> This document uses the following terminology from RFC8941 to specify syntax and parsing: List and Byte Sequence. </ins> Phrases like TLS client certificate authentication or mutually- authenticated TLS are used throughout this document to refer to the process whereby, in addition to the normal TLS server authentication
Original text:
2.1. <del> The headers in this document encode certificates as Structured Field Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </del>  Note that certificates are often stored encoded in a textual format, such as the one described in RFC7468, which is already nearly <del> compatible with a Structured Field Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </del>  2.2.

Reviewer comments:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Revised text:
2.1.  <ins> The headers in this document encode certificates as Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </ins> Note that certificates are often stored encoded in a textual format, such as the one described in RFC7468, which is already nearly  <ins> compatible with a Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </ins> 2.2.
Original text:
contains the end-entity certificate used by the client in the TLS handshake. <del> Client-Cert is an Item Structured Header RFC8941.  Its value MUST be a Byte Sequence (RFC8941).  Its ABNF is: The value of the header is encoded as described in encoding. </del>  The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field

Reviewer comments:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Revised text:
contains the end-entity certificate used by the client in the TLS handshake.  <ins> Client-Cert is a Byte Sequence with the value of the header encoded as described in encoding. </ins> The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field
Original text:
proxy MAY make the certificate chain available to the backend application with the Client-Cert-Chain HTTP header field. <del> Client-Cert-Chain is a List Structured Header RFC8941.  Each item in the list MUST be a Byte Sequence (RFC8941) encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). The header's ABNF is: </del>  The "Client-Cert-Chain" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It MAY have a list of values

Reviewer comments:
try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM

Revised text:
proxy MAY make the certificate chain available to the backend application with the Client-Cert-Chain HTTP header field.  <ins> Client-Cert-Chain is a List (RFC8941).  Each item in the list MUST be a Byte Sequence encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). </ins> The "Client-Cert-Chain" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It MAY have a list of values
Original text:
For example, given the following message: <del> ```http-message HTTP/1.1 200 OK Content-Type: text/plain Transfer- Encoding: chunked Trailer: Expires 4 HTTP 7 Message 10 Signatures 0 Expires: Wed, 9 Nov 2022 07:28:00 GMT ``` </del> The signer decides to add both the Trailer header field as well as <del> the Expires trailer to the signature base: ""@status": 200 "trailer": Expires "expires";tr: Wed, 9 Nov 2022 07:28:00 GMT " </del>  <del> IF a field is available as both a header and trailer in a message, both values MAY be signed separately.  The values of header fields and trailer fields of the same name MUST NOT be combined. </del>  Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per HTTP, it is NOT RECOMMENDED

Reviewer comments:
The HTTP message in Sec. 2.1.4 of draft -14 is not formatted correctly (both HTML and plain text).
NAME

Revised text:
For example, given the following message:  The signer decides to add both the Trailer header field as well as  <ins> the Expires trailer to the signature base, along with the status code derived component: </ins>  <ins> If a field is available as both a header and trailer in a message, both values MAY be signed, but the values MUST be signed separately. The values of header fields and trailer fields of the same name MUST NOT be combined for purposes of the signature. </ins> Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per HTTP, it is NOT RECOMMENDED
Original text:
ORIGIN frame is sent from servers to clients on the server's control stream.  2.1. The ORIGIN frame has a nearly identical layout to that used in

Reviewer comments:
in the manner discussed in London: Admitting it exists, but we don't care.
Section 2 of includes these nuggets: to this specification MAY define flags. See . and but future updates to this specification (through IETF consensus) might use them to change its semantics. The first four flags (0x1, 0x2, 0x4, and 0x8) are reserved for backwards-incompatible changes; therefore, when any of them are set, the ORIGIN frame containing them MUST be ignored by clients conforming to this specification, unless the flag's semantics are understood. The remaining flags are reserved for backwards-compatible changes and do not affect processing by clients conformant to this specification. HTTP/3 frames don't have a Flags field in the generic frame layout. So, while I'm not sure we'll ever see a use of these flags in H2 ORIGIN, it might bite us later if it happened. I see a few options for dealing with this: Option 1) Defer. Future us will have a job to do trying to make H2 and H3 compatible if a flags related change is proposed. Perhaps its worth a little note to make sure people are aware of this divergence consideration. Option 2) Add a Flags field () to the HTTP/3 frame and add in all the same considerations about backards-(in)compatibility Option 3) Encode the flags in the frame type by picking a large enough value. A bit yuck. I'm leaning towards option 1.

Revised text:
ORIGIN frame is sent from servers to clients on the server's control stream. <ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification does not define a mechanism for communicating such flags in HTTP/3. </ins> 2.1. The ORIGIN frame has a nearly identical layout to that used in