jiebi/TextFlow huggingface dataset:
Original text:
parameter's functionality is already covered when the "key" parameter is used on a dictionary item, since "key" requires strict serialization of the value.  The "bs" parameter, which requires the <del> raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </del>  Additional parameters can be defined in the HTTP Signature Component Parameters registry established in component-param-registry.

Reviewer comments:
Proposed fix in URL - note that this is an incompatible change.
FWFW, if the argument is that not escaping the escape character is actually ok for this purpose...: in that case the prose should actually explain this.
I actually do think it's ok to not escape the escape character. If you've got non-ASCII header values you're already kinda out in the weeds in terms of processing the header bytes. Ultimately the signature base really only needs to have bytes, but its input is constrained to ASCII because (1) all derived components are already constrained this way (2) component names and arguments are already constrained and (3) header component values (here) are SUPPOSED to be constrained to ASCII, but might not be in some weird corners as you've pointed out. All that the newly-introduced percent encoding is doing is putting bumpers around the weird corner that isn't supposed to happen but might in some cases. I'd honestly be happier with putting advice to use the binary sequence wrapping ( flag) on problematic non-ASCII header values instead of doing percent-encoding and requiring universal escape of the escape character when the encoding isn't going to hit the VAST majority of use cases. That would reverse the previously-applied fix but I'm fine that.
That works for me. If we combine that with the "MUST produce an error for non-ASCII" in the signature base generation (and people actually do that check), we should be safe.
OK, I'll work on that, unless you want to take a swing at it.. Since we've already got the cut-out for fields that don't behave nicely as lists (specifically Set-Cookie), we've got a good space to put this advice. I think an error on generation makes perfect sense here too. I'll back out the percent-encoding for non-ASCII headers at the same time (but note it'll stay for query parameters, where I do think it makes sense to use).

Revised text:
parameter's functionality is already covered when the "key" parameter is used on a dictionary item, since "key" requires strict serialization of the value.  The "bs" parameter, which requires the  <ins> raw bytes of the field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters can be defined in the HTTP Signature Component Parameters registry established in component-param-registry.
Original text:
request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- sensitive as per HTTP.  While conventionally standardized method <del> names are uppercase US-ASCII (STD80), no transformation to the input method value's case is performed. </del>  For example, the following request message:

Reviewer comments:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Revised text:
request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- sensitive as per HTTP.  While conventionally standardized method  <ins> names are uppercase ASCII, no transformation to the input method value's case is performed. </ins> For example, the following request message:
Original text:
The resulting values are encoded as follows: <del> If the encoding were not applied, the resultant value would be: </del>  <del> This base string violates the constraints on component values, and is therefore invalid. </del>  2.2.9.

Reviewer comments:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Revised text:
The resulting values are encoded as follows:  <ins> If the encoding were not applied, the resultant values would be: </ins>  <ins> This base string contains characters that violate the constraints on component names and values, and is therefore invalid. </ins> 2.2.9.
Original text:
2.5. <del> The signature base is a US-ASCII (STD80) string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </del>  Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a

Reviewer comments:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Revised text:
2.5.  <ins> The signature base is a ASCII string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a
Original text:
field value with parameters Produce an error if the output string contains any non-ASCII <del> (STD80) characters. </del>  Return the output string.

Reviewer comments:
Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.

Revised text:
field value with parameters Produce an error if the output string contains any non-ASCII  <ins> (ASCII) characters. </ins> Return the output string.
Original text:
the trailer section prevents digest validation, possibly leading to processing of invalid data. <del> Not every hashing algorithm is suitable for use in the trailer section, some may require to preprocess the whole content before sending a message (e.g., see I-D.thomson-http-mice). </del>  6.5.

Reviewer comments:
LGTM
On the list, Rob Sayre asked: I agree it seems we can improve the text here a little. Maybe NAME or NAME can elaborate as to why a digest trailer is not suitable in this case?
The reason is that in order to produce a MICE hash, you need to process the content in reverse order. Therefore, there is no reason not to put the hash in the header. The advantage you get in return is that you can process the response in natural order.
Thanks martin. We should just say it that way, because it is clearer to the reader. I'll follow up with a PR.

Revised text:
the trailer section prevents digest validation, possibly leading to processing of invalid data.  <ins> One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent.  However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits.  For example, Merkle Integrity Content Encoding I-D.thomson-http-mice requires content to be processed in reverse order.  This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header or trailer section. </ins> 6.5.
Original text:
name in the "next-hop-aliases" list would be the name that ultimately resolved to one or more addresses. <del> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </del>  For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop

Reviewer comments:
The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.

Revised text:
name in the "next-hop-aliases" list would be the name that ultimately resolved to one or more addresses.  <ins> The list of DNS names in "next-hop-aliases" uses a comma (",") as a separator between names.  Note that if a comma is included in a name itself, the comma must be encoded as described in encoding. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop
Original text:
aliases" to indicate that no CNAME records were encountered when resolving the next hop's name.  3. In order to include the "next-hop-aliases" parameter, a proxy needs

Reviewer comments:
The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.

Revised text:
aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. <ins> 2.1. DNS names commonly just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as follows: It is also possible for a DNS name to include a period character (".") within a label, instead of as a label separator.  In this case, the period character MUST be first escaped as "\.".  Since the "\" character itself will be percent-encoded, the name "dot\.label.example.com" would be encoded within a "next-hop-aliases" parameter as follows: Upon parsing this name, "dot%5C.label" MUST be treated as a single label. Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </ins> 3. In order to include the "next-hop-aliases" parameter, a proxy needs
Original text:
The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the <del> client trusts its proxy to provide accurate information.  This </del>  information is intended to be used as a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy.  5. This document registers the "next-hop-aliases" parameter in the "HTTP

Reviewer comments:
NAME please take a look!
Without going through a proxy, clients implement CNAME cloaking mitigations on the basis of DNS information they see during resolution, which is totally reasonable. If resolution is subverted (or whatever) and the CNAME information is modified, these client checks might not work. When going through a proxy, the proxy is the one doing DNS resolution, so it seems like any sort of funny business that one might do to DNS answers for the proxy might affect the client's ability to implement cloaking mitigations correctly. The security considerations might benefit from a bit of expansion to cover this additional aspect of the threat model.

Revised text:
The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the  <ins> client trusts the proxy to provide accurate information.  This </ins> information is intended to be used as a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy. <ins> Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts.  However, the CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking.  In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name resolution and proxies performing DNS name resolution on behalf of client.  A malicious proxy could also choose to not report these CNAME chains in order to hide the cloaking.  In general, clients can trust information included (or not included) in the "next-hop- aliases" parameter to the degree that the proxy and any resolvers used by the proxy are trusted. </ins> 5. This document registers the "next-hop-aliases" parameter in the "HTTP
Original text:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540. </del>  A client that receives such an advertisement MAY make future requests intended for the associated origin (RFC6454) to the identified

Reviewer comments:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Revised text:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses  <ins> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests intended for the associated origin (RFC6454) to the identified
Original text:
Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT <del> present them.  Established connections with client certificates MAY be reused, however. </del>  2.1.

Reviewer comments:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Revised text:
Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT  <ins> present them.  Connections that use client certificates for other reasons MAY be reused, though client certificates MUST NOT affect the responses to requests for "http" resources. </ins> 2.1.
Original text:
both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. <del> Because of the risk of server confusion about individual requests' schemes (see confuse), clients MUST NOT send "http" requests on a connection that has previously been used for "https" requests, unless the http-opportunistic origin object well-known fetched over that connection has a "mixed-scheme" member whose value is "true". </del>  2.3.

Reviewer comments:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.

Revised text:
both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection.  <ins> Because of the potential for server confusion about the scheme of requests (see confuse), clients MUST NOT send "http" requests on a connection prior to successfully retrieving a valid http- opportunistic resource that contains the origin (see well-known). The primary purpose of this check is to provide a client with some assurance that a server understands this specification and has taken steps to avoid being confused about request scheme. </ins> 2.3.