jiebi/CodeConvo huggingface dataset:
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
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> <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. <del> For example, GZIP supports mulitple compression levels.  Such </del> <ins> For example, GZIP supports multiple compression levels.  Such </ins> 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> <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 <del> provide a proof of integrity "at rest" unless the whole (e.g. </del> <ins> provide a proof of integrity "at rest" unless the whole (e.g., </ins> encoded) content is persisted. 6.6.
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
text: for making security decisions about the identity of a resource accessed through the proxy. <del> 4. </del> <ins> 5. </ins> This document registers the "next-hop-aliases" parameter in the "HTTP Proxy-Status Parameters" registry <<https://www.iana.org/assignments/
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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. <del> For example, when serving a response for this signed request: </del> <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. <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> <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:
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
text: 7.3.7. <del> When applying content-request-response or signature-multiple to a </del> <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
Code change:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Related discussion:
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> <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:
Code change:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Related discussion:
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> <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:
Code change:
Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base

Related discussion:
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> <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
Code change:
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.

Related discussion:
text: 3. This section defines the abstract types for Structured Fields, and <del> summarises how those types are serialised into textual HTTP fields. </del> <ins> summarizes how those types are serialized into textual HTTP fields. </ins> In summary:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
text: Byte Sequences can be conveyed in Structured Fields. <del> When serialised in a textual HTTP field, a Byte Sequence is delimited </del> <ins> When serialized in a textual HTTP field, a Byte Sequence is delimited </ins> with colons and encoded using base64 (RFC4648, Section 4).  For example: