jiebi/TextFlow huggingface dataset:
Original text:
extensions. The authentication proofs described in this document are not bound to <del> individual HTTP requests; if the same user sends an authentication proof on multiple requests they will all be identical.  This allows </del>  for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts

Reviewer comments:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Revised text:
extensions. The authentication proofs described in this document are not bound to  <ins> individual HTTP requests; if the key is used for authentication proofs on multiple requests they will all be identical.  This allows </ins> for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts
Original text:
If type is "integer": <del> Parse input_number as an integer and let output_number be the product of the result and sign. </del>  Otherwise:

Reviewer comments:
OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.

Revised text:
If type is "integer":  <ins> Let output_number be an Integer that is the result of parsing input_number as an integer. </ins> Otherwise:
Original text:
If the number of characters after "." in input_number is greater than three, fail parsing. <del> Parse input_number as a decimal number and let output_number be the product of the result and sign. </del>  Return output_number.

Reviewer comments:
OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.

Revised text:
If the number of characters after "." in input_number is greater than three, fail parsing.  <ins> Let output_number be a Decimal that is the result of parsing input_number as a decimal number. Let output_number be the product of output_number and sign. </ins> Return output_number.
Original text:
protocols.  Doing so can undermine the security guarantees of the authentication.  9. 9.1.

Reviewer comments:
Based on
Right now the document contains the (user ID) parameter. Thinking about it some more, this is more about describing the key than the user, see httpwg/http-extensions. In addition to that change, we should add text warning about the tracking risks or this and how to avoid these issues.
It seems to me that there's room for both user-ID type uses for the "u" (in the employee remote access model, e.g.) as well as the more indirect key-indicator type uses (in the Internet Freedom model of distributed communities). I'm especially interested in the latter - use cases where users can prove they are in possession of a valid secret without requiring a hard user identifier (one that attaches them to a permanent/billable/irrevocable external identifier). The draft does not currently provide an Authentication Scheme that directly offers this latter capability, however (though it's possible to overload on the "u"/"k" parameter if the server and client agree on the scheme for doing that). I'm unable to steelman the case for "u" (or "k") being a "super-cookie". The imagined use cases in my head have this scheme tied to a single service provider and employed on the first hop. I don't understand the language being used in the list commentary on this topic (e.g., "Each site (*) could get a different key pair and key identifier."). My assumption has been sites issue credentials as they see fit without reference to any other site. The commentary implies to me that there is some overriding entity distributing credentials to many sites (a la Privacy Pass). I did not think Unprompted Authentication addresses that space. Further, if indeed we need to address that space, it seems to me the "super-cookie" burden of proof is then with THAT scheme, not Unprompted Authentication. The "document it" point might be the salient one: "This is probably another case where documenting a little more detail about the usage context could help.". Here's a start: Sites offering Unprompted Authentication are able to link requests from individuals clients via the Authentication Schemes provided. However, requests as not linkable across other sites if the credentials used are private to individual sites.

Revised text:
protocols.  Doing so can undermine the security guarantees of the authentication. <ins> Sites offering Unprompted Authentication are able to link requests that use the same key for the Authentication Schemes provided. However, requests are not linkable across other sites if the keys used are private to the individual sites using Unprompted Authentication. </ins> 9. 9.1.
Original text:
Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support <del> this specification will validate the authentication received from the client themselves, then inform the upstream HTTP server of the presence of valid authentication using some other mechanism. </del>  8.

Reviewer comments:
Ilari suggests on the :
to this. It's been implemented for exported authenticators and isn't too challenging.

Revised text:
Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support  <ins> this specification have two options: The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of valid authentication. The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </ins> 8.
Original text:
However, transport-oriented integrity provides a limited utility because it is opaque to the application layer and only covers the extent of a single connection.  HTTP messages often travel over a <del> chain of separate connections, in between connections there is a </del>  possibility for unintended or malicious data corruption.  An HTTP integrity mechanism can provide the means for endpoints, or applications using HTTP, to detect data corruption and make a choice

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
However, transport-oriented integrity provides a limited utility because it is opaque to the application layer and only covers the extent of a single connection.  HTTP messages often travel over a  <ins> chain of separate connections.  In between connections there is a </ins> possibility for unintended or malicious data corruption.  An HTTP integrity mechanism can provide the means for endpoints, or applications using HTTP, to detect data corruption and make a choice
Original text:
The HTTP fields defined in this document can be used for HTTP integrity.  Senders choose a hashing algorithm and calculate a digest <del> from an input related to the HTTP message, the algorithm identifier </del>  and digest are transmitted in an HTTP field.  Receivers can validate the digest for integrity purposes.  Hashing algorithms are registered <del> in the "Hash Algorithms for HTTP Digest Fields" (see algorithms). </del>  Selecting the data on which digests are calculated depends on the use <del> case of HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </del>  <del> There are use-cases where a simple digest of the HTTP content bytes </del>  is required.  The "Content-Digest" request and response header and trailer field is defined to support digests of content (RFC9110); see content-digest. <del> For more advanced use-cases, the "Repr-Digest" request and response </del>  header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to selected representation data (RFC9110).  Basing "Repr-Digest" on the <del> selected representation makes it straightforward to apply it to use- </del>  cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
The HTTP fields defined in this document can be used for HTTP integrity.  Senders choose a hashing algorithm and calculate a digest  <ins> from an input related to the HTTP message.  The algorithm identifier </ins> and digest are transmitted in an HTTP field.  Receivers can validate the digest for integrity purposes.  Hashing algorithms are registered  <ins> in the "Hash Algorithms for HTTP Digest Fields" registry (see establish-hash-algorithm-registry). </ins> Selecting the data on which digests are calculated depends on the use  <ins> case of the HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </ins>  <ins> There are use cases where a simple digest of the HTTP content bytes </ins> is required.  The "Content-Digest" request and response header and trailer field is defined to support digests of content (RFC9110); see content-digest.  <ins> For more advanced use cases, the "Repr-Digest" request and response </ins> header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to selected representation data (RFC9110).  Basing "Repr-Digest" on the  <ins> selected representation makes it straightforward to apply it to use </ins> cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see
Original text:
thus providing coverage for HTTP content or representation data. This specification does not define means for authentication, <del> authorization or privacy. </del>  1.3.

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
thus providing coverage for HTTP content or representation data. This specification does not define means for authentication,  <ins> authorization, or privacy. </ins> 1.3.
Original text:
Integer, and List. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", "user agent" and </del>  "content" in this document are to be interpreted as described in RFC9110. This document uses the line folding strategies described in FOLDING. Hashing algorithm names respect the casing used in their definition <del> document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c"). </del>  The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas "digest" is only used in

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
Integer, and List. The definitions "representation", "selected representation",  <ins> "representation data", "representation metadata", "user agent", and </ins> "content" in this document are to be interpreted as described in RFC9110. This document uses the line folding strategies described in FOLDING. Hashing algorithm names respect the casing used in their definition  <ins> document (e.g., SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g., "sha", "crc32c"). </ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas "digest" is only used in
Original text:
Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on <del> the wire" is dependent on other transformations (e.g. transfer </del>  codings for HTTP/1.1 - see RFC9112).  To help illustrate HTTP representation concepts, several examples are provided in resource- representation.

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on  <ins> the wire" is dependent on other transformations (e.g., transfer </ins> codings for HTTP/1.1 - see RFC9112).  To help illustrate HTTP representation concepts, several examples are provided in resource- representation.
Original text:
reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to <del> be weak, broken or experimental.  If a registration request attempts </del>  to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional".

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to  <ins> be weak, broken, or experimental.  If a registration request attempts </ins> to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional".
Original text:
multiple hops or system boundaries.  Even a simple mechanism for end- to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to <del> a HTML parser, video player etc. for parsing. </del>  Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
multiple hops or system boundaries.  Even a simple mechanism for end- to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to  <ins> an HTML parser, video player, etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could
Original text:
additional considerations when Integrity fields are included in this set. <del> There are no restrictions placed on the type or format of digitial </del>  signature that Integrity fields can be used with.  One possible approach is to combine them with HTTP Message Signatures SIGNATURES. <del> Digests explicitly depend on the "representation metadata" (e.g. the </del>  values of "Content-Type", "Content-Encoding" etc).  A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering.  For example, an actor could

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
additional considerations when Integrity fields are included in this set.  <ins> There are no restrictions placed on the type or format of digital </ins> signature that Integrity fields can be used with.  One possible approach is to combine them with HTTP Message Signatures SIGNATURES.  <ins> Digests explicitly depend on the "representation metadata" (e.g., the </ins> values of "Content-Type", "Content-Encoding" etc).  A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering.  For example, an actor could
Original text:
processing of invalid data. Not every hashing algorithm is suitable for use in the trailer <del> section, some may require to pre-process the whole payload before sending a message (e.g. see I-D.thomson-http-mice). </del>  6.5. Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. <del> For example, GZIP supports mulitple compression levels.  Such </del>  encoding parameters are generally not communicated as representation <del> metadata, for instance different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </del>  content coding defined in RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to <del> provide a proof of integrity "at rest" unless the whole (e.g. </del>  encoded) content is persisted. 6.6.

Reviewer comments:
s/ise-case/use case e.g. -> e.g., nit pass

Revised text:
processing of invalid data. Not every hashing algorithm is suitable for use in the trailer  <ins> section, some may require to preprocess the whole payload before sending a message (e.g., see I-D.thomson-http-mice). </ins> 6.5. Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs.  <ins> For example, GZIP supports multiple compression levels.  Such </ins> encoding parameters are generally not communicated as representation  <ins> metadata.  For instance, different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </ins> content coding defined in RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to  <ins> provide a proof of integrity "at rest" unless the whole (e.g., </ins> encoded) content is persisted. 6.6.
Original text:
3.  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

Reviewer comments:
I think the alias draft should probably have a (non-normative) reference to , in particular noting that: can be populated from the output of . can be used to emulate or substitute for .
I think the flag to only gives you the "canonical name" which is the final CNAME target at the end of the CNAME chain. If you want the full set of interior names across a chain of multiple CNAME records I don't believe you can retrieve that with .
Yeah, I'm hesitant to add references to system APIs like , and particularly for the reason given above. NAME what do you think?
I think AI_CANONNAME is important historical context here. You can't understand where the draft is coming from without it. I also think that this extension will often be implemented by wrapping getaddrinfo, and some guidance about whether that is compliant would be appropriate. I think Robert's comment raises a good example of why this is not trivial, and hence is worth mentioning.
I'm not sure is really required to understand the context of the draft. We don't use it at all on iOS/macOS implementations for current CNAME cloaking detection. I do see that it may be good to warn that it is not sufficient to just wrap up .
Thanks LGTM

Revised text:
3. <ins> In order to include the "next-hop-aliases" parameter, a proxy needs to have access to the chain of alias names and canonical names received in CNAME records. Implementations ought to note that the full chain of names might not available in common DNS resolution APIs, such as "getaddrinfo". "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use "getaddrinfo" as described above. 4. </ins> 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