jiebi/CodeConvo huggingface dataset:
Code change:
HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)

Related discussion:
text: The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload body and message body.  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> the payload body (see Section 7.3.3 of SEMANTICS).  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the payload body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range <del> Requests or methods such as HEAD, while the message body is dependent on transfer codings and other transformations: resource- </del> <ins> Requests or methods such as HEAD, while the way the payload body is transferred "on the wire" is dependent on other transformations (eg. transfer codings for HTTP/1.1 see 6.1 of HTTP11): resource- </ins> representation contains several examples to help illustrate those effects.
Code change:
HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)

Related discussion:
text: after validating the Digest. If received in trailers, Digest MUST NOT be discarded; instead it MAY <del> be merged in the header section (See Section 7.1.2 of !MESSAGING=I- D.ietf-httpbis -messaging). </del> <ins> be merged in the header section (See Section 5.6.2 of SEMANTICS). </ins> Not every digest-algorithm is suitable for trailers, as they may require to pre-process the whole payload before sending a message
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 7.1.2 of SEMANTICS) two more </del> <ins> no content codings (see Section 7.1.2 of SEMANTICS) two more digest- </ins> algorithms are added ("id-sha-256" and "id-sha-512"). 1.3.
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: Digest coverage for either the resource's "representation data" or "selected representation data" communicated via HTTP. <del> Support for multiple digest algorithms. </del> <ins> Support for multiple digest-algorithms. </ins> Negotiation of the use of digests.
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: SEMANTICS together with an indication of the algorithm used (and any parameters) <del> The checksum is computed using one of the "digest-algorithms" listed in algorithms and then encoded in the associated format. </del> <ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. </ins> The example below shows the "sha-256" digest-algorithm which uses base64 encoding.
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 5. <del> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters can be supplied. </del> <ins> Digest-algorithm values are used to indicate a specific digest computation.  For some digest-algorithms, one or more parameters can be supplied. </ins> The BNF for "parameter" is defined in Section 5.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive.
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: digest-algorithm values.  The registry contains the tokens listed below. <del> Some algorithms, although registered, have since been found vulnerable: the "MD5" algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> <ins> Some digest-algorithms, although registered, rely on vulnerable algorithms: the "MD5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 9.2. Requests without a payload body can still send a "Digest" field <del> applying the digest algorithm to an empty representation. </del> <ins> applying the digest-algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values in the response are the same.
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 12.3. <del> This memo updates the "MD5" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "MD5" digest-algorithm in the HTTP Digest </ins> Algorithm Values [5] registry: Digest Algorithm: MD5
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 12.4. <del> This memo updates the "CRC32c" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "CRC32c" digest-algorithm in the HTTP Digest </ins> Algorithm Values [6] registry: Digest Algorithm: CRC32c
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 12.5. <del> This memo updates the "SHA" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "SHA" digest-algorithm in the HTTP Digest </ins> Algorithm Values [7] registry: Digest Algorithm: SHA
Code change:
is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.

Related discussion:
text: 12.6. <del> This memo updates the "ADLER32" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "ADLER32" digest-algorithm in the HTTP Digest </ins> Algorithm Values [8] registry: Digest Algorithm: ADLER32
Code change:
Aligns a part of the doc with the SHA-1 deprecation we decided in We correctly deprecated SHA-1 but in this part we left it as NOT RECOMMENDED.

Related discussion:
text: The status of "MD5" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. <del> The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </del> <ins> The status of "SHA" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. </ins> The status for "CRC32c" has been updated to "standard".
Code change:
cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing

Related discussion:
text: transmission of software update files that would have the background urgency being associated.  However, in the worst case, the asymmetry between the precedence declared by multiple clients might cause <del> responses going to one end client to be delayed totally after those </del> <ins> responses going to one user agent to be delayed totally after those </ins> going to another. <del> In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the priority of "u=1, i" (i.e. round-robin) regardless of the value of the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients. </del> <ins> In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements. </ins> A server can determine if a request came from an intermediary through configuration, or by consulting if that request contains one of the
Code change:
cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing

Related discussion:
text: Via (RFC7230, Section 5.7.1) <del> Responding to requests coming through an intermediary in a round- robin manner works well when the network bottleneck exists between the intermediary and the end client, as the intermediary would be buffering the responses and then be forwarding the chunks of those buffered responses based on the prioritization scheme it implements. A sophisticated server MAY use a weighted round-robin reflecting the urgencies expressed in the requests, so that less urgent responses would receive less bandwidth in case the bottleneck exists between the server and the intermediary. </del> 8.2. It is common for CDN infrastructure to support different HTTP
Code change:
NAME correctly pointed out that the draft contained a made up error code. On inspection, we need to define specific error codes for both H2 and H3. This change does that.
The latest version of the draft states: There is no such error either in or in . Perhaps HTTP/3's H3FRAMEERROR was meant?
Dang, I worked from memory and should've spent 2 minutes for checking. I'll get this fixed up thanks.

Related discussion:
text: A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> Field Value MUST be treated as a connection error.  In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type H3_FRAME_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open.  Furthermore, HTTP/3 offers no guaranteed
Code change:
details encryption quirks: encryption functions may produce different results with the same data this means that if I GET an encrypted resource twice, I could get two different digest values so the digest value is just good to validate the ongoing message and not for further processing of the data at rest, unless I store the encrypted data or use an algorithm which in turn might disclose information. This
looks good, just some nits.

Related discussion:
text: "Digest" may expose information details of encrypted payload when the checksum is computed on the unencrypted data.  An example of that is <del> the use of the "id-sha-256" digest-algorithm in conjuction with the </del> <ins> the use of the "id-sha-256" digest-algorithm in conjunction with the </ins> encrypted content-coding RFC8188. <ins> The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) payload body is persisted. </ins> 11.9. ...
Code change:
[x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)

Related discussion:
text: However, there are cases where relying on this alone is insufficient. An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption <del> of data at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> of data in flight or at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document defines a mechanism that acts on HTTP representation- data.  It can be combined with other mechanisms that protect
Code change:
[x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)

Related discussion:
text: not the "representation metadata". Besides, it allows to protect "representation data" from buggy <del> manipulation, buggy compression, etc. </del> <ins> manipulation, undesired "transforming proxies" (see Section 6.5 of SEMANTICS), etc. </ins> Moreover, identity digest-algorithms (eg. "id-sha-256" and "id-sha- 512") allow piecing together a resource from different sources (e.g.
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: 2.2. <ins> An individual member in the value of a Dictionary Structured Field is identified by the lowercased field name, followed by a semicolon "":"", followed by the member name.  An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in Section 4.1.2 of StructuredFields on a Dictionary containing only that member. 2.2.1. This section contains non-normative examples of canonicalized values for Dictionary Structured Field Members given the following example header field, whose value is assumed to be a Dictionary: The following table shows example canonicalized values for different content identifiers, given that field: 2.3. A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the lowercased field name, followed by a semicolon "":"", followed by N expressed as an Integer String.  A list prefix is canonicalized by applying the serialization algorithm described in Section 4.1.1 of StructuredFields on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </ins> The signature's Creation Time (signature-metadata) is identified by <del> the "(created)" identifier. </del> <ins> the "*created" identifier. </ins> Its canonicalized value is an Integer String containing the signature's Creation Time expressed as the number of seconds since
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: simplifies processing and avoids timezone management required by specifications such as RFC3339. <del> 2.3. </del> <ins> 2.5. </ins> The signature's Expiration Time (signature-metadata) is identified by <del> the "(expired)" identifier. </del> <ins> the "*expires" identifier. </ins> Its canonicalized value is a Decimal String containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [4] of POSIX.1. <del> 2.4. </del> <ins> 2.6. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the <del> "(request-target)" identifier. </del> <ins> "*request-target" identifier. </ins> Its value is canonicalized as follows:
Code change:
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)

Related discussion:
text: header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1. </del> <ins> 2.6.1. </ins> The following table contains non-normative example HTTP messages and <del> their canonicalized "(request-target)" values. </del> <ins> their canonicalized "*request-target" values. </ins> 3.