jiebi/TextFlow huggingface dataset:
Original text:
for making security decisions about the identity of a resource accessed through the proxy. <del> 4. </del>  This document registers the "next-hop-aliases" parameter in the "HTTP Proxy-Status Parameters" registry <<https://www.iana.org/assignments/

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:
for making security decisions about the identity of a resource accessed through the proxy.  <ins> 5. </ins> This document registers the "next-hop-aliases" parameter in the "HTTP Proxy-Status Parameters" registry <<https://www.iana.org/assignments/
Original text:
IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at <del> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </del>  8.  References

Reviewer comments:
Follow up to the IANA review of the digest spec. We asked them to deprectae the old registry, so lets add a note to it to clarify what the new expectations of that registry are.

Revised text:
IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at  <ins> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2] and replace the note on this registry with the following text: </ins> 8.  References
Original text:
A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context <del> could include additional information known to the application, such as an external host name. </del>  The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context  <ins> could include additional information known to the application through configuration, such as an external host name. If binding between a request and response is needed using the mechanism in content-request-response, all elements of the request and response message that would be required to provide properties of such a binding. </ins> The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is
Original text:
Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same <del> named component from both the request and response message. </del>  The "req" parameter MAY be combined with other parameters as appropriate for the component identifier, such as the "key" parameter for a dictionary field. <del> For example, when serving a response for this signed request: </del>  This would result in the following unsigned response message: The server signs the response with its own key, including the "@status" code and several header fields in the covered components. <del> To cryptographically link the response to the request, the server includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </del>  The signed response message is:

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same  <ins> named component from both the request and response message, respectively. </ins> The "req" parameter MAY be combined with other parameters as appropriate for the component identifier, such as the "key" parameter for a dictionary field.  <ins> For example, when serving a response for this request: </ins> This would result in the following unsigned response message: The server signs the response with its own key, including the "@status" code and several header fields in the covered components.  <ins> While this covers a reasonable amount of the response for this application, the server additionally includes several components derived from the original request message that triggered this response.  In this example, the server includes the method, authority, path, and content digest from the request in the covered components of the response.  The Content-Digest for both the request and the response are included under the response signature.  For the application in this example, the query is deemed not to be relevant to the response and is therefore not covered.  Other applications would make different decisions based on application needs as discussed in application. The signature base for this example is: </ins> The signed response message is:
Original text:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm.  5. While a signer is free to attach a signature to a request or response

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. <ins> While the proxy could additionally include the client's Signature value and Signature-Input fields from the original message in the new signature's covered components, this practice is NOT RECOMMENDED due to known weaknesses in signing signature values as discussed in security-sign-signature.  The proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server.  In this example, it is possible for the origin server to have additional information in its signature context to account for the change in authority, though this practice requires additional configuration and extra care as discussed in security-context- multiple-signatures.  In other applications, the origin server will not be able to verify the original signature itself but will still want to verify that the proxy has done the appropriate validation of the client's signature.  An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely. </ins> 5. While a signer is free to attach a signature to a request or response
Original text:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <del> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </del>  field in the request, the server is unable to include a signature that covers the request's content.

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple.  <ins> Applications that make use of the content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </ins> field in the request, the server is unable to include a signature that covers the request's content.
Original text:
7.3.7. <del> When applying content-request-response or signature-multiple to a </del>  message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value.  While it would seem that this practice

Reviewer comments:
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.

Revised text:
7.3.7.  <ins> When applying the content-request-response or signature-multiple to a </ins> message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value.  While it would seem that this practice
Original text:
uses the following ABNF rules: "VCHAR", "SP", "DQUOTE", "LF".  This document uses the following ABNF rules from STRUCTURED-FIELDS: "sf- string", "inner-list", "parameters".  This document uses the <del> following ABNF rules from HTTP: "field-content". </del>  In addition to those listed above, this document uses the following terms:

Reviewer comments:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Revised text:
uses the following ABNF rules: "VCHAR", "SP", "DQUOTE", "LF".  This document uses the following ABNF rules from STRUCTURED-FIELDS: "sf- string", "inner-list", "parameters".  This document uses the  <ins> following ABNF rules from HTTP and HTTP1: "field-content", "obs- fold", "obs-text". </ins> In addition to those listed above, this document uses the following terms:
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, no transformation to the input method value's case is performed. </del>  For example, the following request message:

Reviewer comments:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

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 US-ASCII (STD80), no transformation to the input method value's case is performed. </ins> For example, the following request message:
Original text:
2.5. <del> The signature base is a US-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. </del>  Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a

Reviewer comments:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Revised text:
2.5.  <ins> 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. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a
Original text:
as defined in signature-params, i.e. an Inner List structured field value with parameters  Return the output string. If covered components reference a component identifier that cannot be

Reviewer comments:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Revised text:
as defined in signature-params, i.e. an Inner List structured field value with parameters <ins> Produce an error if the output string contains any non-ASCII (STD80) characters. </ins> Return the output string. If covered components reference a component identifier that cannot be
Original text:
3. This section defines the abstract types for Structured Fields, and <del> summarises how those types are serialised into textual HTTP fields. </del>  In summary:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
3. This section defines the abstract types for Structured Fields, and  <ins> summarizes how those types are serialized into textual HTTP fields. </ins> In summary:
Original text:
An empty List is denoted by not serializing the field at all.  This implies that fields defined as Lists have a default empty value. <del> When serialised as a textual HTTP field, each member is separated by </del>  a comma and optional whitespace.  For example, a field whose value is defined as a List of Tokens could look like:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
An empty List is denoted by not serializing the field at all.  This implies that fields defined as Lists have a default empty value.  <ins> When serialized as a textual HTTP field, each member is separated by </ins> a comma and optional whitespace.  For example, a field whose value is defined as a List of Tokens could look like:
Original text:
individual Items and the Inner List itself can be Parameterized (param). <del> When serialised in a textual HTTP field, Inner Lists are denoted by </del>  surrounding parenthesis, and their values are delimited by one or more spaces.  A field whose value is defined as a List of Inner Lists of Strings could look like:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
individual Items and the Inner List itself can be Parameterized (param).  <ins> When serialized in a textual HTTP field, Inner Lists are denoted by </ins> surrounding parenthesis, and their values are delimited by one or more spaces.  A field whose value is defined as a List of Inner Lists of Strings could look like:
Original text:
Note that parameters are ordered, and parameter keys cannot contain uppercase letters. <del> When serialised in a textual HTTP field, a Parameter is separated </del>  from its Item or Inner List and other Parameters by a semicolon.  For example:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
Note that parameters are ordered, and parameter keys cannot contain uppercase letters.  <ins> When serialized in a textual HTTP field, a Parameter is separated </ins> from its Item or Inner List and other Parameters by a semicolon.  For example:
Original text:
undefined or unknown, unless the field's specification specifically disallows them. <del> When serialised as a textual HTTP field, Members are ordered as </del>  serialized and separated by a comma with optional whitespace.  Member keys cannot contain uppercase characters.  Keys and values are separated by "=" (without whitespace).  For example:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
undefined or unknown, unless the field's specification specifically disallows them.  <ins> When serialized as a textual HTTP field, Members are ordered as </ins> serialized and separated by a comma with optional whitespace.  Member keys cannot contain uppercase characters.  Keys and values are separated by "=" (without whitespace).  For example:
Original text:
Byte Sequence (binary) can be specified, along with a character encoding (preferably UTF-8 STD63). <del> When serialised in a textual HTTP field, Strings are delimited with </del>  double quotes, using a backslash ("\") to escape double quotes and backslashes.  For example:

Reviewer comments:
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.

Revised text:
Byte Sequence (binary) can be specified, along with a character encoding (preferably UTF-8 STD63).  <ins> When serialized in a textual HTTP field, Strings are delimited with </ins> double quotes, using a backslash ("\") to escape double quotes and backslashes.  For example: