jiebi/CodeConvo huggingface dataset:
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: This takes into account the effect of the HTTP semantics on the messages; for example, the payload data can be affected by Range Requests or methods such as HEAD, while the way the payload data is <del> transferred "on the wire" is dependent on other transformations (eg. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11): resource- representation contains several examples to help illustrate those effects. </del> <ins> transferred "on the wire" is dependent on other transformations (e.g. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11).  To help illustrate how such things affect "Digest", several examples are provided in resource-representation. </ins> A representation digest consists of the value of a checksum computed on the entire selected "representation data" (see Section 8 of SEMANTICS) of a resource identified according to Section 6.4.2 of <del> SEMANTICS together with an indication of the algorithm used </del> <ins> SEMANTICS together with an indication of the algorithm used: </ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format. <del> The example below shows the "sha-256" digest-algorithm which uses </del> <ins> The example below shows the "sha-256" digest-algorithm that uses </ins> base64 encoding. 3.
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: digest values as defined in representation-digest.  It can be used in both requests and responses. <ins> For example: </ins> The relationship between "Content-Location" (see Section 8.8 of SEMANTICS) and "Digest" is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. <del> "Digest" can be sent in a trailer section.  When using incremental digest-algorithms this allows the sender and the receiver to </del> <ins> "Digest" can be sent in a trailer section.  When an incremental digest-algorithms is used, the sender and the receiver can </ins> dynamically compute the digest value while streaming the content. <del> Two examples of its use are </del> 4. The "Want-Digest" field indicates the sender's desire to receive a
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: sender's preferred digest-algorithm is the one (or ones) with the highest "qvalue". <del> Two examples of its use are </del> <ins> Two examples of its use are: </ins> 5. Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but the lower case is preferred. </del> <ins> All digest-algorithm values are case-insensitive but lower case is preferred. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: 6.1. <del> In PATCH requests the representation digest MUST be computed on the </del> <ins> In PATCH requests, the representation digest MUST be computed on the </ins> patch document because the representation metadata refers to the patch document and not to the target resource (see Section 2 of PATCH). <del> In PATCH responses the representation digest MUST be computed on the </del> <ins> In PATCH responses, the representation digest MUST be computed on the </ins> selected representation of the patched resource. <del> "Digest" usage with PATCH is thus very similar to the POST one, but with the resource's own semantic partly implied by the method and by the patch document. </del> <ins> "Digest" usage with PATCH is thus very similar to POST, but with the resource's own semantic partly implied by the method and by the patch document. </ins> 7.
Code change:
This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!

Related discussion:
text: 8. <del> This document obsoletes the usage of parameters with "Digest" introduced in Section 4.1.1 and 4.2 of RFC3230 because this feature has not been widely deployed and complicates field-value processing. </del> <ins> Section 4.1.1 and 4.2 of RFC3230 defined field parameters.  This document obsoletes the usage of parameters with "Digest" because this feature has not been widely deployed and complicates field-value processing. </ins> <del> Field parameters provided a common way to attach additional information to a representation-data-digest, but if they are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior. </del> <ins> RFC3230 intended field parameters to provide a common way to attach additional information to a representation-data-digest.  However, if parameters are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior. </ins> <del> A digest-algorithm can still be parameterized defining its own way to encode parameters into the representation-data-digest in such a way as to mitigate security risks related to its computation. </del> <ins> A digest-algorithm can still be parameterized by defining its own way to encode parameters into the representation-data-digest, in such a way as to mitigate security risks related to its computation. </ins> 9.
Code change:
This is a proposal to address issue /cc NAME
I've updated the graph in section 2 to note the new range. PTAL.
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: contain at least one byte of padding and a 16 octet authentication tag. <del> Each record contains between 1 and 256 octets of padding, inserted </del> <ins> Each record contains between 2 and 65537 octets of padding, inserted </ins> into a record before the enciphered content.  Padding consists of a <del> length byte, followed that number of zero-valued octets.  A receiver MUST fail to decrypt if any padding octet other than the first is non-zero, or a record has more padding than the record size can accommodate. </del> <ins> two octet unsigned integer in network byte order, followed that number of zero-valued octets.  A receiver MUST fail to decrypt if any padding octet other than the first two are non-zero, or a record has more padding than the record size can accommodate. </ins> The nonce for each record is a 96-bit value constructed from the record sequence number and the input keying material.  Nonce
Code change:
The I-D contains the following TODO we might add a SETTINGS parameter that indicates the next hop that the connection is NOT coalesced (see URL). I'd like to track that discussion here. Namely, with all the changes in the meantime, does NAME think that there is still a problem that needs fixing? OR can we close with no action?
I don't think anything additional is needed. We've got the two standard header options to indicate an intermediary is involved, that was the main point of the original discussion in Singapore IIRC. I think this won't matter all that much in practice, given warmed up edge-to-origin connections, pops being able to serve cached resources in between, etc. Origin owners really concerned with performance will know if their setup is coalescing or not (then the question is if origin server software allows tweaking prioritization behavior, but that's a general concern). CDN owners seeing bad origin behaviour will probably just overwrite the priority information instead of forwarding in practice. In short, I think the current text should suffice here, as I don't think many servers would support switching to RR when seeing an explicit "warning: coalescing intermediary" signal either way.
Thanks NAME In that case I've created to simply remove the TODO text, which will act to resolve this issues.

Related discussion:
text: problematic and presents possible mitigations, or where unfairness is desirable. <del> TODO: Discuss if we should add a signal that mitigates this issue. For example, we might add a SETTINGS parameter that indicates the next hop that the connection is NOT coalesced (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). </del> 10.1. When an intermediary coalesces HTTP requests coming from multiple
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: 2. <del> The "aesgcm128" HTTP content-coding indicates that a payload has been </del> <ins> The "aesgcm" HTTP content-coding indicates that a payload has been </ins> encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in RFC5116, Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128 bit content encryption key.
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: Key header field (crypto-key) can be included to describe how the content encryption key is derived or retrieved. <del> The "aesgcm128" content-coding uses a single fixed set of encryption </del> <ins> The "aesgcm" content-coding uses a single fixed set of encryption </ins> primitives.  Cipher suite agility is achieved by defining a new content-coding scheme.  This ensures that only the HTTP Accept- Encoding header field is necessary to negotiate the use of encryption. <del> The "aesgcm128" content-coding uses a fixed record size.  The resulting encoding is a series of fixed-size records, with a final record that is one or more octets shorter than a fixed sized record. </del> <ins> The "aesgcm" content-coding uses a fixed record size.  The resulting encoding is a series of fixed-size records, with a final record that is one or more octets shorter than a fixed sized record. </ins> The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: header field (crypto-key).  The first step of HKDF is therefore: The info parameter to HKDF is set to the ASCII-encoded string <del> "Content-Encoding: aesgcm128", a single zero octet and an optional </del> <ins> "Content-Encoding: aesgcm", a single zero octet and an optional </ins> context string: Unless otherwise specified, the context is a zero length octet
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: The "keyid" parameter corresponds to the "keyid" parameter in the Encryption header field. <del> The "aesgcm128" parameter contains the URL-safe base64 RFC4648 octets of the input keying material. </del> <ins> The "aesgcm" parameter contains the URL-safe base64 RFC4648 octets of the input keying material. </ins> The "dh" parameter contains an ephemeral Diffie-Hellman share. This form of the header field can be used to encrypt content for a
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: 4.1. <del> The "aesgcm128" parameter is decoded and used as the input keying material for the "aesgcm128" content encoding.  The "aesgcm128" parameter MUST decode to at least 16 octets in order to be used as input keying material for "aesgcm128" content encoding. </del> <ins> The "aesgcm" parameter is decoded and used as the input keying material for the "aesgcm" content encoding.  The "aesgcm" parameter MUST decode to at least 16 octets in order to be used as input keying material for "aesgcm" content encoding. </ins> <del> Other key determination parameters can be ignored if the "aesgcm128" </del> <ins> Other key determination parameters can be ignored if the "aesgcm" </ins> parameter is present. 4.2.
Code change:
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .

Related discussion:
text: 7.1. This memo registers the "encrypted" HTTP content-coding in the HTTP <del> Content Codings Registry, as detailed in aesgcm128. </del> <ins> Content Codings Registry, as detailed in aesgcm. </ins> <del> Name: aesgcm128 </del> <ins> Name: aesgcm </ins> Description: AES-GCM encryption with a 128-bit content encryption key