jiebi/TextFlow huggingface dataset:
Original text:
3. <del> This section describes representations of merkle tree structures in </del>  CBOR. Some of the structures such as the construction of a merkle tree

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
3.  <ins> This section describes representations of merkle proof structures in </ins> CBOR. Some of the structures such as the construction of a merkle tree
Original text:
several different representations. Some differences in representations are necessary to support <del> efficient verification of proofs and compatibility with deployed tree algorithms used in specific implementations. </del>  3.1. <del> A Merkle tree root is signed with COSE_Sign1, creating a Signed Merkle Tree Root: </del>  Protected header parameters:

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
several different representations. Some differences in representations are necessary to support  <ins> efficient verification of different kinds of inclusion proofs and for compatibility with deployed tree algorithms used in specific implementations. </ins> 3.1.  <ins> A Merkle root is signed with COSE_Sign1: </ins> Protected header parameters:
Original text:
tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value type: int / tstr. <del> tree size (label: TBD): OPTIONAL.  Merkle tree size as the number of leaves.  Value type: uint. </del> A COSE profile of this specification may add further header <del> parameters, for example to identify the signer. </del>  <del> Payload: Merkle tree root hash bytes according to tree alg (i.e., header params tell you what the alg id is here) </del>  <del> Note: The payload is just a byte string representing the Merkle tree root hash (and not some wrapper structure) so that it can be detached (see defintion of payload in https://www.rfc-editor.org/rfc/ rfc9052#section-4.1) and easily re-computed from an inclusion path and leaf bytes.  This allows to design other structures that force re-computation and prevent faulty implementations (forgetting to match a computed root with one embedded in a signature). </del>  <del> One example of a Signed Merkle Tree Proof is a "transparent signed statement" or "claim" as defined in I-D.ietf-scitt-architecture. </del>  3.2.

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value type: int / tstr.  A COSE profile of this specification may add further header  <ins> parameters, for example to identify the signer or add a timestamp. Envelope Payload: A Merkle tree root according to the tree alg. </ins>  <ins> The envelope payload can be detached, since it can be recomputed by the verifier. </ins>  <ins> Forcing a verifier to perform re-computation can prevent faulty implementations. </ins>  <ins> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. </ins> 3.2.
Original text:
inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with <del> Signed Merkle Tree Proof. </del>  If the tree size and leaf index is known, then a compact inclusion path variant can be used: <del> Otherwise, the direction for each path step must be included: </del>  FIXME bit vector: 0 right, 1 left, so no bit labels

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with  <ins> Signed Inclusion Proof. Editors note: We may want to move inclusion path representations to the specification that is required to register a new algorithm in the proposed tree algorithms registry. Editors note: We recommend tree algorithm simple take the inclusion path as opaque bytes. </ins> If the tree size and leaf index is known, then a compact inclusion path variant can be used:  <ins> Leaf index is also sometimes referred to as sequence number. Otherwise, the direction each path step must be included: </ins> FIXME bit vector: 0 right, 1 left, so no bit labels
Original text:
themselves and both the index and direction can be left out in the path: <del> Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to derive private information from them. TODO: Should leaf index be part of inclusion path (IndexAwareInclusionPath) or outside? </del>  <del> TODO: Define root computation algorithm for each inclusion path type TODO: Do we need both inclusion path types? what properties does each type have? [1] </del>  <del> TODO: Should the inclusion path be opaque (bstr) and fixed by the tree algorithm?  It seems this is orthogonal and the choice of inclusion path type should be application-specific. </del>  <del> 3.3. </del>  <del> A signed Merkle tree proof is a CBOR array containing a signed tree </del>  root, an inclusion path, extra data for the tree algorithm, and the payload. <del> "extra_data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  A use case for this field is to implement blinding. </del>  <del> TODO: maybe rename "extra_data" </del>  <del> 3.4. </del>  <del> TODO: define a multi-leaf variant of a signed Merkle tree proof like in: </del>  https://github.com/transmute-industries/merkle-proof

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
themselves and both the index and direction can be left out in the path:  <ins> Presence of leaf index, and whether it is an input or an output is tree algorithm specific. </ins>  <ins> 3.3. </ins>  <ins> An inclusion proof is a CBOR array containing a merkle tree root, an inclusion path, extra data for the tree algorithm, and the payload. </ins>  <ins> 3.4. </ins>  <ins> A signed inclusion proof is a CBOR array containing a signed tree </ins> root, an inclusion path, extra data for the tree algorithm, and the payload.  <ins> "extra-data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  See sec-leaf- blinding-example for an example use case for this field to enable leaf blinding as described in sec-leaf-blinding. </ins>  <ins> 3.5. </ins>  <ins> 3.5.1. This signed mulitple inclusion proof representation relies on 2 lists to enable proof of inclusion for multiple payloads in a given signed merkle root. </ins>  <ins> Note that the extra-data may be ommited if not required by the tree algorithm, and that leaf payloads may be detached. TODO: refine multi-leaf variant of a signed inclusion proof like in: </ins> https://github.com/transmute-industries/merkle-proof
Original text:
4. <del> This document establishes a registry of Merkle tree algorithms with </del>  the following initial contents: <del> [FIXME] exploration table, what should go into -00? </del> Each tree algorithm defines how to compute the root node from a sequence of leaves each represented by payload and extra data.  Extra data is algorithm-specific and should be considered opaque. <del> 4.1. </del>  <del> The "RFC9162_SHA256" tree algorithm uses the Merkle tree definition from RFC9162 with SHA-256 hash algorithm. </del>  <del> For n > 1 inputs, let k be the largest power of two smaller than n. </del>  <del> where "d(0)" is the payload.  This algorithm takes no extra data. </del>  <del> 5. </del>  TBD <del> 6. </del>  <del> TBD </del>  7.

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
4.  <ins> This document establishes a registry of merkle tree algorithms with </ins> the following initial contents:  Each tree algorithm defines how to compute the root node from a sequence of leaves each represented by payload and extra data.  Extra data is algorithm-specific and should be considered opaque.  <ins> 5. </ins>  <ins> TBD </ins>  <ins> 5.1. </ins>  <ins> In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that an attacker may be able to learn the content of undisclosed payloads, by brute forcing the values adjacent to the disclosed payloads through application of the cryptographic hash function and comparison to the the disclosed inclusion paths.  This kind of attack can be mitigated by including a cryptographic nonce in the construction of the leaf, however this nonce must then disclosed along side an inclusion proof which increases the size of multiple payload signed inclusion proofs. </ins>  <ins> 6. </ins> TBD  <ins> 6.1. </ins>  <ins> The choice of cryptographic hash function is the primary primitive impacting the security of authenticating payload inclusion in a merkle root.  Tree algorithm designers should review the latest guidance on selecting a suitable cryptographic hash function. </ins> 7.
Original text:
IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point.  7.2. IANA will be asked to add a new registry "TBD" to the list that <del> appears at https://www.iana.org/assignments/. </del>  The rest of this section defines the subregistries that are to be created within the new "TBD" registry.

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. <ins> Name: tree_alg Label: TBD Value type: tree_alg Value registry: See Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </ins> 7.2. IANA will be asked to add a new registry "TBD" to the list that  <ins> appears at IANA Assignments [1]. </ins> The rest of this section defines the subregistries that are to be created within the new "TBD" registry.
Original text:
7.2.1. IANA will be asked to establish a registry of tree algorithm <del> identifiers, named "Tree Algorithms", with the following registration procedures: TBD </del>  <del> The "Tree Algorithms" registry initially consists of: </del>  <del> The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD]. </del>  8.  References 8.1.  URIs <del> [1] https://github.com/ietf-scitt/cose-merkle-tree-proofs/issues/6 </del> 

Reviewer comments:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Revised text:
7.2.1. IANA will be asked to establish a registry of tree algorithm  <ins> identifiers, named "Tree Algorithms" to be administered under a Specification Required policy RFC8126. Template: Identifier: The two-byte identifier for the algorithm Tree Algorithm: The name of the algorithm </ins>  <ins> Reference: Where this algorithm is defined </ins>  <ins> Initial contents: Provided in </ins> 8.  References 8.1.  URIs  <ins> [1] https://www.iana.org/assignments/ </ins>
Original text:
The "Connection" header field allows the sender to list desired control options for the current connection.  When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field.

Reviewer comments:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Revised text:
The "Connection" header field allows the sender to list desired control options for the current connection. <ins> Connection options are case-insensitive. </ins> When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field.
Original text:
message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header <del> field itself (or replace it with the intermediary's own connection </del>  options for the forwarded message). Hence, the Connection header field provides a declarative way of

Reviewer comments:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Revised text:
message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header  <ins> field itself (or replace it with the intermediary's own control </ins> options for the forwarded message). Hence, the Connection header field provides a declarative way of
Original text:
to be deployed without fear that they will be blindly forwarded by older intermediaries. <del> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' </del>  semantics.  This includes but is not limited to: <del> The Connection header field's value has the following grammar: Connection options are case-insensitive. </del> A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content.  For example,

Reviewer comments:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Revised text:
to be deployed without fear that they will be blindly forwarded by older intermediaries.  <ins> Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' </ins> semantics.  This includes but is not limited to:  A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content.  For example,
Original text:
status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more <del> parts of the selected representation that correspond to the satisfiable ranges found in the request's header field (header.range). </del>  When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the

Reviewer comments:
See URL
Mailing list discussion:
We might want to clarify the nature of the response elsewhere, but this seems fine.

Revised text:
status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more  <ins> parts of the selected representation. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the
Original text:
If the request method is GET, the response status code is , and the entire response header section has been received, a cache <del> MAY store a response body that is not complete (message.framing) if the stored response is recorded as being incomplete.  Likewise, a </del>  response MAY be stored as if it were an incomplete

Reviewer comments:
In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"

Revised text:
If the request method is GET, the response status code is , and the entire response header section has been received, a cache  <ins> MAY store a response that is not complete (message.framing) provided that the stored response is recorded as being incomplete.  Likewise, a </ins> response MAY be stored as if it were an incomplete
Original text:
7.1. <del> Storing a malicious payload in a cache can extend the reach of an </del>  attacker to affect multiple users.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.

Reviewer comments:
In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"

Revised text:
7.1.  <ins> Storing malicious content in a cache can extend the reach of an </ins> attacker to affect multiple users.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.
Original text:
identical, as is the case for the compression codings defined in compression.codings.  Values to be added to this namespace require IETF Review (see RFC8126), and MUST conform to the purpose of transfer coding defined in this specification.

Reviewer comments:
That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?
I can avoid the SHOULD NOT. I used different text because for transfer codings "we" actually own the registry, while for content types we do not...
Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple should be sufficient.
I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.
My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive. While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.
NAME - so are you ok with this change?
I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.
Continuing from URL In the current spec, nothing is said about how to handle transfer-parameters. Notably, nothing is said about the case sensitivity of the parameter key. This results in a conflict with the TE header: if you see a "q" token, you cannot know if it is a transfer-parameter vs a t-ranking. It is noted that the "q" token is case insensitive in section 4.3.
See URL
OK. An edge case of an edge case. Note that among the currently registered transfer codings, none defines parameters. Drastic options might be: Disallow parameters on transfer codings (and thus also on content codings) Remove quality values on transfer coding negotiation. More realistic: in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE". Should I make a proposal for this?
Actually, we have a similar situation for Accept:; see :
Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.

Revised text:
identical, as is the case for the compression codings defined in compression.codings. <ins> The header field (header.te) uses a pseudo parameter named "q" as rank value when multiple transfer codings are acceptable.  Future registrations of transfer codings SHOULD NOT define parameters called "q" (case-insensitively) in order to avoid ambiguities. </ins> Values to be added to this namespace require IETF Review (see RFC8126), and MUST conform to the purpose of transfer coding defined in this specification.
Original text:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version.  4. Each major version of HTTP defines its own syntax for the inclusion

Reviewer comments:
HTTP defines its own protocol versions as having two numbers "URL" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax. Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.
SGTM
Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:
+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a URL field.
The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments. So this is entirely in the spirit of the existing specifications.
That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.
all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.
The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that. However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.
Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me). If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense. But I'd ask the editors to go through these 49++ times and see if it wouldn't be possible to replace some of them with "is". "is" just reads so much more easily where it's appropriate than "ought".

Revised text:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <ins> When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </ins> 4. Each major version of HTTP defines its own syntax for the inclusion