jiebi/TextFlow huggingface dataset:
Original 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>  <del> Other key determination parameters can be ignored if the "aesgcm128" </del>  parameter is present. 4.2.

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:
4.1.  <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>  <ins> Other key determination parameters can be ignored if the "aesgcm" </ins> parameter is present. 4.2.
Original text:
7.1. This memo registers the "encrypted" HTTP content-coding in the HTTP <del> Content Codings Registry, as detailed in aesgcm128. </del>  <del> Name: aesgcm128 </del>  Description: AES-GCM encryption with 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:
7.1. This memo registers the "encrypted" HTTP content-coding in the HTTP  <ins> Content Codings Registry, as detailed in aesgcm. </ins>  <ins> Name: aesgcm </ins> Description: AES-GCM encryption with a 128-bit content encryption key
Original text:
7.4.2. <del> Parameter Name: aesgcm128 </del>  Purpose: Provide an explicit input keying material value for the <del> aesgcm128 content encoding. </del>  Reference: this document

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:
7.4.2.  <ins> Parameter Name: aesgcm </ins> Purpose: Provide an explicit input keying material value for the  <ins> aesgcm content encoding. </ins> Reference: this document
Original text:
3.3. <del> When attempting to extend priorities, care must be taken to ensure any use of existing parameters leaves them either unchanged or modified in a way that is backwards compatible for peers that are unaware of the extended meaning. </del>  For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range

Reviewer comments:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Revised text:
3.3.  <ins> When attempting to define new parameters, care must be taken so that they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new parameters should not change the interpretation of or modify the predefined parameters in a way that is not backwards compatible or fallback safe. </ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range
Original text:
graphical user agent could send a "visible" parameter to indicate if the resource being requested is within the viewport.  4. The Priority HTTP header field can appear in requests and responses.

Reviewer comments:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Revised text:
graphical user agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. <ins> Generic parameters are preferred over vendor-specific, application- specific or deployment-specific values.  If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment). 3.3.1. New Priority parameters can be defined by registering them in the HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. The Expert(s) should consider the following factors when evaluating requests: Community feedback If the parameters are sufficiently well-defined and adhere to the guidance provided in new-parameters. Registration requests should use the following template: Name: [a name for the Priority Parameter that matches key] Description: [a description of the parameter semantics and value] Reference: [to a specification defining this parameter] See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests. </ins> 4. The Priority HTTP header field can appear in requests and responses.
Original text:
This document  14.  References 14.1.  URIs

Reviewer comments:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Revised text:
This document <ins> Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [5] and populate it with the types defined in parameters; see register for its associated procedures. </ins> 14.  References 14.1.  URIs
Original text:
[2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/priorities 

Reviewer comments:
Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.

Revised text:
[2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/priorities <ins> [4] https://iana.org/assignments/http-priority [5] https://iana.org/assignments/http-priority </ins>
Original text:
below. Some digest-algorithms, although registered, rely on vulnerable <del> 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. </del> 

Reviewer comments:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Revised text:
below. Some digest-algorithms, although registered, rely on vulnerable  <ins> algorithms and MUST not be used: "md5", see CMU-836068 and NO-MD5; "sha", see IACR-2020-014 and NO-SHA1. See the references above for further information. </ins>
Original text:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now <del> vulnerable to collision attacks CMU-836068. </del>  Reference: RFC1321, RFC4648, this document.

Reviewer comments:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Revised text:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now  <ins> vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Original text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to <del> collision attacks IACR-2020-014. </del>  Reference: RFC3174, RFC6234, RFC4648, this document.

Reviewer comments:
references RFC6515 and 6194 for deprecating md5 and sha1 Since there are RFCs, we could even skip explaining that those algorithms are vulnerable to collisions.
cc: NAME
NAME feel free to PR for the rest of the algorithms :P
In s12.2, should refer (informatively) to and for IETF references that deprecate the use of md5 and sha1, respectively.
Thanks for the pointers, sgtm
You beat me to the PR!

Revised text:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to  <ins> collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Original text:
Name: connection_terminated Description: The intermediary's connection to the next hop was <del> closed before any part of the response was received.  If some part was received, see http_response_incomplete. </del>  Extra Parameters: None. Recommended HTTP status code: 502  2.4.9. Name: connection_timeout

Reviewer comments:
Signed-off-by: Piotr Sikora
So, what's the difference to , then? Should we just remove perhaps?
can be also sent if the connection is terminated before or when sending HTTP request. is more generic and can be sent in response to other events as well (e.g. read/write timeouts). But more importantly, either can be sent in response to the same event (i.e. connection terminated when receiving HTTP response), depending on the existing proxy implementation or various policies, i.e. "proxy should be as specific as it wants to be" from your last email.

Revised text:
Name: connection_terminated Description: The intermediary's connection to the next hop was  <ins> closed before complete response was received. </ins> Extra Parameters: None. Recommended HTTP status code: 502 <ins> Notes: Responses with this error type might not have been generated by the intermediary. </ins> 2.4.9. Name: connection_timeout
Original text:
_RFC EDITOR: please remove this section before publication_ <del> This work was originally based on draft-cavage-http-signatures-12, but has since diverged from it, to reflect discussion since adoption by the HTTP Working Group.  In particular, it addresses issues that have been identified, and adds features to support new use cases.  It is a work-in-progress and not yet suitable for deployment. </del>  1.

Reviewer comments:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Revised text:
_RFC EDITOR: please remove this section before publication_  <ins> Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/signatures [3]. </ins> 1.
Original text:
complete access to or control over HTTP messages (such as a web browser's JavaScript environment), or may be using libraries that abstract away the details of the protocol (such as the Java <del> HTTPClient library [1]).  These applications need to be able to </del>  generate and verify signatures despite incomplete knowledge of the HTTP message.

Reviewer comments:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Revised text:
complete access to or control over HTTP messages (such as a web browser's JavaScript environment), or may be using libraries that abstract away the details of the protocol (such as the Java  <ins> HTTPClient library [4]).  These applications need to be able to </ins> generate and verify signatures despite incomplete knowledge of the HTTP message.
Original text:
Signature may be verified multiple times, potentially by different entities. <del> The term "Unix time" is defined by POSIX.1 section 4.16 [2]. </del>  This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split

Reviewer comments:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Revised text:
Signature may be verified multiple times, potentially by different entities.  <ins> The term "Unix time" is defined by POSIX.1 section 4.16 [5]. </ins> This document contains non-normative examples of partial and complete HTTP messages.  To improve readability, header fields may be split
Original text:
7.1.  URIs <del> [1] https://openjdk.java.net/groups/net/httpclient/intro.html </del>  <del> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del>  V1_chap04.html#tag_04_16

Reviewer comments:
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.

Revised text:
7.1.  URIs  <ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/signatures [4] https://openjdk.java.net/groups/net/httpclient/intro.html </ins>  <ins> [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16
Original text:
of SEMANTICS. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", and "payload data" in this document are to be interpreted as described in SEMANTICS. </del>  Algorithm names respect the casing used in their definition document (eg.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (eg.

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
of SEMANTICS. The definitions "representation", "selected representation",  <ins> "representation data", "representation metadata", and "content" in this document are to be interpreted as described in SEMANTICS. </ins> Algorithm names respect the casing used in their definition document (eg.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (eg.
Original text:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload data (see Section 6.4 of SEMANTICS).  It uses the </del>  representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the payload data, or not contained at all: </del>  This takes into account the effect of the HTTP semantics on the <del> messages; for example, the payload data can be affected by Range Requests or methods such as HEAD, while the way the payload data is 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 </del>  illustrate how such things affect "Digest", several examples are provided in resource-representation.

Reviewer comments:
Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".

Revised text:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of  <ins> the content (see Section 6.4 of SEMANTICS).  It uses the </ins> representation data (see Section 8.1 of SEMANTICS), that can be fully  <ins> or partially contained in the content, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the  <ins> messages; for example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is 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 </ins> illustrate how such things affect "Digest", several examples are provided in resource-representation.