jiebi/TextFlow huggingface dataset:
Original text:
The goals do not include: <del> The digest mechanism described here does not cover the full HTTP message nor its semantic, as representation metadata are not included in the checksum. </del>  <del> The digest mechanisms described here cover only representation and selected representation data, and do not protect the integrity of </del>  associated representation metadata or other message fields. <del> The digest mechanisms described here are not meant to support authentication of the source of a digest or of a message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </del>  Digest mechanisms do not provide message privacy. <del> The digest mechanisms described here are not meant to support authorization or other kinds of access controls. </del>  1.4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC2119 and RFC8174) when, and only when, they appear in all </del>  capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated

Reviewer comments:
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!

Revised text:
The goals do not include:  <ins> Digest mechanisms do not cover the full HTTP message nor its semantic, as representation metadata is not included in the checksum. </ins>  <ins> Digest mechanisms cover only representation and selected representation data, and do not protect the integrity of </ins> associated representation metadata or other message fields.  <ins> Digest mechanisms do not support authentication of the source of a digest, message or anything else.  These mechanisms, therefore, are not a sufficient defense against many kinds of malicious attacks. </ins> Digest mechanisms do not provide message privacy.  <ins> Digest mechanisms do not support authorization or other kinds of access controls. </ins> 1.4. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all </ins> capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated
Original 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>  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>  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>  base64 encoding. 3.

Reviewer comments:
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!

Revised 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  <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  <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.  <ins> The example below shows the "sha-256" digest-algorithm that uses </ins> base64 encoding. 3.
Original text:
digest values as defined in representation-digest.  It can be used in both requests and responses.  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

Reviewer comments:
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!

Revised 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
Original 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>  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

Reviewer comments:
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!

Revised text:
algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it.  <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.  4. The "Want-Digest" field indicates the sender's desire to receive a
Original text:
sender's preferred digest-algorithm is the one (or ones) with the highest "qvalue". <del> Two examples of its use are </del>  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>  The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed

Reviewer comments:
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!

Revised text:
sender's preferred digest-algorithm is the one (or ones) with the highest "qvalue".  <ins> Two examples of its use are: </ins> 5. Digest-algorithm values are used to indicate a specific digest computation.  <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
Original text:
6.1. <del> In PATCH requests the representation digest MUST be computed on the </del>  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>  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>  7.

Reviewer comments:
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!

Revised text:
6.1.  <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).  <ins> In PATCH responses, the representation digest MUST be computed on the </ins> selected representation of the patched resource.  <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.
Original 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>  <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>  <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>  9.

Reviewer comments:
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!

Revised text:
8.  <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>  <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>  <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.
Original 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>  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>  The nonce for each record is a 96-bit value constructed from the record sequence number and the input keying material.  Nonce

Reviewer comments:
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 .

Revised text:
contain at least one byte of padding and a 16 octet authentication tag.  <ins> Each record contains between 2 and 65537 octets of padding, inserted </ins> into a record before the enciphered content.  Padding consists of a  <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
Original 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

Reviewer comments:
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.

Revised text:
problematic and presents possible mitigations, or where unfairness is desirable.  10.1. When an intermediary coalesces HTTP requests coming from multiple
Original text:
2. <del> The "aesgcm128" HTTP content-coding indicates that a payload has been </del>  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.

Reviewer comments:
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 .

Revised text:
2.  <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.
Original 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>  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>  The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is

Reviewer comments:
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 .

Revised text:
Key header field (crypto-key) can be included to describe how the content encryption key is derived or retrieved.  <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.  <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
Original 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>  context string: Unless otherwise specified, the context is a zero length octet

Reviewer comments:
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 .

Revised text:
header field (crypto-key).  The first step of HKDF is therefore: The info parameter to HKDF is set to the ASCII-encoded string  <ins> "Content-Encoding: aesgcm", a single zero octet and an optional </ins> context string: Unless otherwise specified, the context is a zero length octet
Original 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>  The "dh" parameter contains an ephemeral Diffie-Hellman share. This form of the header field can be used to encrypt content for a

Reviewer comments:
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 .

Revised text:
The "keyid" parameter corresponds to the "keyid" parameter in the Encryption header field.  <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