jiebi/TextFlow huggingface dataset:
Original text:
This document defines two digest integrity mechanisms for HTTP. First, representation data integrity, which acts on representation <del> data (Section 3.2 of SEMANTICS).  Second, content digest integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end-to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries.  Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del>  This document obsoletes RFC3230.

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
This document defines two digest integrity mechanisms for HTTP. First, representation data integrity, which acts on representation  <ins> data (Section 3.2 of SEMANTICS).  Second, content integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end- to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries. Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document obsoletes RFC3230.
Original text:
(e.g.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (e.g. "sha", "crc32c").  2. The representation digest is an integrity mechanism for HTTP

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
(e.g.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (e.g. "sha", "crc32c"). <ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas digest is only used in relation to the value of the fields. </ins> 2. The representation digest is an integrity mechanism for HTTP
Original text:
SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del>  content. A non-comprehensive set of examples showing the impacts of

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
SEMANTICS. When an incremental digest-algorithm is used, the sender and the  <ins> receiver can dynamically compute a checksum while streaming the </ins> content. A non-comprehensive set of examples showing the impacts of
Original text:
Section 6.5.1 of SEMANTICS. When an incremental digest-algorithm is used, the sender and the <del> receiver can dynamically compute the digest value while streaming the </del>  content. 5.

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
Section 6.5.1 of SEMANTICS. When an incremental digest-algorithm is used, the sender and the  <ins> receiver can dynamically compute the checksum while streaming the </ins> content. 5.
Original text:
e.g. according to the type and status of the primary document in which the algorithm is defined; "insecure" when the <del> algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </del>  Description: the description of the digest-algorithm and its encoding

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
e.g. according to the type and status of the primary document in which the algorithm is defined; "insecure" when the  <ins> algorithm is insecure; "reserved" when the algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding
Original text:
Insecure digest algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial <del> setting; for example, when signing the digest of content for </del>  authenticity. The registry is initialized with the tokens listed below.

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
Insecure digest algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial  <ins> setting; for example, when signing digest fields' values for </ins> authenticity. The registry is initialized with the tokens listed below.
Original text:
Such signatures can protect one or more HTTP fields and there are additional considerations when "Digest" is included in this set. <del> Since digest fields are hashes of resource representations, they </del>  explicitly depend on the "representation metadata" (e.g. the values of "Content-Type", "Content-Encoding" etc).  A signature that protects "Digest" but not other "representation metadata" can expose

Reviewer comments:
Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.

Revised text:
Such signatures can protect one or more HTTP fields and there are additional considerations when "Digest" is included in this set.  <ins> Since digest fields are checksums of resource representations, they </ins> explicitly depend on the "representation metadata" (e.g. the values of "Content-Type", "Content-Encoding" etc).  A signature that protects "Digest" but not other "representation metadata" can expose
Original text:
character sets used for the encoding. Insecure digest algorithms MAY be used to preserve integrity against <del> accidental change, but MUST NOT be used in a potentially adversarial </del>  setting; for example, when signing the digest of content for authenticity.

Reviewer comments:
Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM

Revised text:
character sets used for the encoding. Insecure digest algorithms MAY be used to preserve integrity against  <ins> corruption, but MUST NOT be used in a potentially adversarial </ins> setting; for example, when signing the digest of content for authenticity.
Original text:
This document specifies a data integrity mechanism that protects HTTP "representation data" or content, but not HTTP header and trailer <del> fields, from certain kinds of accidental corruption. </del>  Digest fields are not intended to be a general protection against malicious tampering with HTTP messages.  This can be achieved by

Reviewer comments:
Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM

Revised text:
This document specifies a data integrity mechanism that protects HTTP "representation data" or content, but not HTTP header and trailer  <ins> fields, from certain kinds of corruption. </ins> Digest fields are not intended to be a general protection against malicious tampering with HTTP messages.  This can be achieved by
Original text:
Digest Algorithm: sha-512 Description: The SHA-512 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del>  Reference: RFC6234, RFC4648, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: sha-512 Description: The SHA-512 algorithm RFC6234.  The output of this  <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.
Original text:
Digest Algorithm: sha-256 Description: The SHA-256 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del>  Reference: RFC6234, RFC4648, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: sha-256 Description: The SHA-256 algorithm RFC6234.  The output of this  <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.
Original text:
Digest Algorithm: md5 <del> Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del>  Reference: RFC1321, RFC4648, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: md5  <ins> Description: The MD5 algorithm RFC1321.  The output of this algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Original text:
Digest Algorithm: sha Description: The SHA-1 algorithm RFC3174.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del>  Reference: RFC3174, RFC6234, RFC4648, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: sha Description: The SHA-1 algorithm RFC3174.  The output of this  <ins> algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Original text:
Digest Algorithm: unixsum <del> Description: The algorithm computed by the UNIX "sum" command, as defined by the Single UNIX Specification, Version 2 UNIX. </del>  The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: unixsum  <ins> Description: The algorithm used by the UNIX "sum" command UNIX. </ins> The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.
Original text:
Digest Algorithm: unixcksum <del> Description: The algorithm computed by the UNIX "cksum" command, as defined by the Single UNIX Specification, Version 2 </del>  UNIX.  The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: unixcksum  <ins> Description: The algorithm used by the UNIX "cksum" command </ins> UNIX.  The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.
Original text:
Digest Algorithm: adler32 <del> Description: The ADLER32 algorithm is a checksum specified in RFC1950 "ZLIB Compressed Data Format".  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </del>  Reference: RFC1950, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: adler32  <ins> Description: The ADLER32 algorithm RFC1950.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </ins> Reference: RFC1950, this document.
Original text:
Digest Algorithm: crc32c <del> Description: The CRC32c algorithm is a 32-bit cyclic redundancy check.  It achieves a better hamming distance (for better error-detection performance) than many other 32-bit CRC functions.  Other places it is used include iSCSI and SCTP. The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </del>  Reference: RFC4960 appendix B, this document.

Reviewer comments:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Revised text:
Digest Algorithm: crc32c  <ins> Description: The CRC32c algorithm RFC4960.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </ins> Reference: RFC4960 appendix B, this document.
Original text:
protocols that do not have strong ordering guarantees across streams, like HTTP/3 HTTP3. <del> Multiple experiments from independent research (MARX, MEENAN) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </del>  2.1.

Reviewer comments:
I was noted that the citation to Pat Meenan's blog post lacked scientific experimental data and a decent permalink. Since we already acknowledge Pat's original scheme proposal in the acknowledgements, lets just remove this one. To avoid anyone picking up on a lack of multiple citations to match the multiple experiments statement, lets drop that qualifier too.
Makes sense. Thank you for the PR.

Revised text:
protocols that do not have strong ordering guarantees across streams, like HTTP/3 HTTP3.  <ins> Experiments from independent research (MARX) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </ins> 2.1.
Original text:
Abstract <del> This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </del>  1.

Reviewer comments:
based on .
This PR would address both and
also would
based on some twitter feedback URL
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain). End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.

Revised text:
Abstract  <ins> This document defines HTTP extension header fields that allow a TLS terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </ins> 1.