jiebi/TextFlow huggingface dataset:
Original text:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1.1. </del>  The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values. <del> 2.4.2. </del>  HTTP Message Signatures have metadata properties that provide information regarding the signature's generation and/or verification.

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value.  <ins> 2.3.1.1. </ins> The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values.  <ins> 2.3.2. </ins> HTTP Message Signatures have metadata properties that provide information regarding the signature's generation and/or verification.
Original text:
the signature parameters used for the current signature are included in this field. <del> 2.5. </del>  The signature input is a US-ASCII string containing the content that is covered by the signature.  To create the signature input string,

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
the signature parameters used for the current signature are included in this field.  <ins> 2.4. </ins> The signature input is a US-ASCII string containing the content that is covered by the signature.  To create the signature input string,
Original text:
header field that is not present in the message, is not a Dictionary Structured Field, or whose value is malformed. <del> The identifier is a List Prefix member identifier that references a header field that is not present in the message, is not a List Structured Field, or whose value is malformed. </del> The identifier is a Dictionary member identifier that references a member that is not present in the header field value, or whose value is malformed.  E.g., the identifier is ""x-dictionary";key=c" and the value of the "x-dictionary" header field is "a=1, b=2" <del> The identifier is a List Prefix member identifier that specifies more List members than are present the header field.  E.g., the identifier is ""x-list";prefix=3" and the value of the "x-list" header field is "(1, 2)". </del> In the following non-normative example, the HTTP message being signed is the following request:

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
header field that is not present in the message, is not a Dictionary Structured Field, or whose value is malformed.  The identifier is a Dictionary member identifier that references a member that is not present in the header field value, or whose value is malformed.  E.g., the identifier is ""x-dictionary";key=c" and the value of the "x-dictionary" header field is "a=1, b=2"  In the following non-normative example, the HTTP message being signed is the following request:
Original text:
associated registry. Signers SHOULD include "@request-target" in the covered content <del> list list. </del>  Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature

Reviewer comments:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Revised text:
associated registry. Signers SHOULD include "@request-target" in the covered content  <ins> list. </ins> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature
Original text:
MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml media types MUST be processed per the requirements </del>  established by RFC5323. SEARCH requests are both safe and idempotent with regards to the

Reviewer comments:
This can be relaxed to XML with a document element in the "DAV:" namespace, or even to the two element names mentioned in Section 2.2.2 of [RFC5323].

Revised text:
MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or  <ins> application/xml media types with a root element (XML) in the "DAV:" XML namespace (XMLNS) MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the
Original text:
A successful response to a SEARCH request is expected to provide some indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be <del> represented by a 204 No Content response.  If the response includes a </del>  content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond indirectly to the SEARCH request by returning a 3xx Redirection with

Reviewer comments:
This minor nit was the only thing that jumped out at me during a read-through before the interim.

Revised text:
A successful response to a SEARCH request is expected to provide some indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be  <ins> represented by a 204 No Content response.  If the response includes </ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond indirectly to the SEARCH request by returning a 3xx Redirection with
Original text:
the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame.  10. Transport protocols such as TCP and QUIC provide reliability by

Reviewer comments:
This PR talks about the server-side recommendation discussed in URL
This PR really just documents an existing consideration that was quielty overlooked, so I think it's good to merge whenever we feel like
Agreed. Let's merge and see.

Revised text:
the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. <ins> 9.1. An intermediary serving an HTTP connection might split requests over multiple backend connections.  When it applies prioritization rules strictly, low priority requests cannot make progress while requests with higher priorities are inflight.  This blocking can propagate to backend connections, which the peer might interpret as a connection stall.  Endpoints often implement protections against stalls, such as abruptly closing connections after a certain time period.  To reduce the possibility of this occurring, intermediaries can avoid strictly following prioritization and instead allocate small amounts of bandwidth for all the requests that they are forwarding, so that every request can make some progress over time. Similarly, servers SHOULD allocate some amount of bandwidths to streams acting as tunnels. </ins> 10. Transport protocols such as TCP and QUIC provide reliability by
Original text:
reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.  The details of this kind of profiling are the purview of the application and outside the scope of this specification.

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography. <ins> An application using signatures also has to ensure that the verifier will have access to all required information to re-create the signature input string.  For example, a server behind a reverse proxy would need to know the original request URI to make use of identifiers like "@target-uri".  Additionally, an application using signatures in responses would need to ensure that clients receiving signed responses have access to all the signed portions, including any portions of the request that were signed by the server. </ins> The details of this kind of profiling are the purview of the application and outside the scope of this specification.
Original text:
covered by a signature, this document defines content identifiers for data items covered by an HTTP Message Signature as well as the means for combining these canonicalized values into a signature input <del> string. </del>  Some content within HTTP messages can undergo transformations that change the bitwise value without altering meaning of the content (for

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
covered by a signature, this document defines content identifiers for data items covered by an HTTP Message Signature as well as the means for combining these canonicalized values into a signature input  <ins> string.  The values for these items MUST be accessible to both the sender and the receiver of the message, which means these are usually derived from aspects of the HTTP message or signature itself. </ins> Some content within HTTP messages can undergo transformations that change the bitwise value without altering meaning of the content (for
Original text:
such a canonical form. Content identifiers are defined using production grammar defined by <del> RFC8941.  The content identifier is an "sf-string" value.  The </del>  content identifier type MAY define parameters which are included using the "parameters" rule.

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
such a canonical form. Content identifiers are defined using production grammar defined by  <ins> RFC8941.  The content identifier itself is an "sf-string" value.  The </ins> content identifier type MAY define parameters which are included using the "parameters" rule.
Original text:
parameters for this signature, including the covered content list with all associated parameters. <del> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </del> "created": Creation time as an "sf-integer" UNIX timestamp value. Sub-second precision is not supported.

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
parameters for this signature, including the covered content list with all associated parameters.  "created": Creation time as an "sf-integer" UNIX timestamp value. Sub-second precision is not supported.
Original text:
"nonce": A random unique value generated for this signature.  Additional parameters can be defined in the iana-param-contents. The signature parameters are serialized using the rules in RFC8941 as

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
"nonce": A random unique value generated for this signature. <ins> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </ins> Additional parameters can be defined in the iana-param-contents. The signature parameters are serialized using the rules in RFC8941 as
Original text:
In the following non-normative example, the HTTP message being signed is the following request: <del> The covered content consists of the "@request-target" specialty content followed by the "Host", "Date", "Cache-Control", "X-Empty- Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test-key-rsa- pss".  The signature input string for this message with these </del>  parameters is: 3.

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
In the following non-normative example, the HTTP message being signed is the following request:  <ins> The covered content consists of the "@method", "@path", and "@authority" specialty content followed by the "Cache-Control", "X- Empty-Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test- key-rsa-pss".  The signature input string for this message with these </ins> parameters is: 3.
Original text:
specialty content field listed in specialty-content or its associated registry. <del> Signers SHOULD include "@request-target" in the covered content list. </del>  <del> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature metadata parameter can fulfil this role. </del>  Further guidance on what to include in this list and in what order is out of scope for this document.  However, note that

Reviewer comments:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Revised text:
specialty content field listed in specialty-content or its associated registry.  <ins> Signers of a request SHOULD include some or all of the control data in the covered content list, such as the "@method", "@authority", "@target-uri", or some combination thereof. </ins>  <ins> Signers SHOULD include the "created" signature metadata parameter to indicate when the signature was created. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, note that
Original text:
The status code for a response. (content-status-code).  Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry)

Reviewer comments:
This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.

Revised text:
The status code for a response. (content-status-code). <ins> A signature from a request message that resulted in this response message. (content-request-response) </ins> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry)
Original text:
The "@status" identifier MUST NOT be used in a request message.  2.4. The signature input is a US-ASCII string containing the content that

Reviewer comments:
This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.

Revised text:
The "@status" identifier MUST NOT be used in a request message. <ins> 2.3.11. When a signed request message results in a signed response message, the "@request-response" identifier can be used to cryptographically link the request and the response to each other by including the identified request signature value in the response.  This identifier has a single REQUIRED parameter: Identifies which signature from the response to sign. The value is the "sf-binary" representation of the signature value of the referenced request identified by the "key" parameter. For example, when serving this signed request: This would result in the following unsigned response message: The server signs the response with its own key and includes the signature of "sig1" from the request in the signed content of the response.  The signature input string for this example is: The signed response message is: Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response. The "@request-response" identifier MUST NOT be used in a request message. </ins> 2.4. The signature input is a US-ASCII string containing the content that
Original text:
manipulation of the HTTP/2 priority tree.  Extensible priorities does not use stream dependencies, which mitigates this vulnerability. <del> TBD: depending on the outcome of reprioritization discussions, following paragraphs may change or be removed. </del> HTTP2, Section 5.3.4 describes a scenario where closure of streams in the priority tree could cause suboptimal prioritization.  To avoid this, HTTP2 states that "an endpoint SHOULD retain stream

Reviewer comments:
We're keeing reprioritization, no need for this TBD any longer.
Thank you for noticing it.

Revised text:
manipulation of the HTTP/2 priority tree.  Extensible priorities does not use stream dependencies, which mitigates this vulnerability.  HTTP2, Section 5.3.4 describes a scenario where closure of streams in the priority tree could cause suboptimal prioritization.  To avoid this, HTTP2 states that "an endpoint SHOULD retain stream
Original text:
and the value string. If the sum of the lengths of the name string and the value string <del> is more than 4096 bytes, abort these steps and ignore the set- </del>  cookie-string entirely. The cookie-name is the name string, and the cookie-value is the

Reviewer comments:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Revised text:
and the value string. If the sum of the lengths of the name string and the value string  <ins> is more than 4096 octets, abort these steps and ignore the set- </ins> cookie-string entirely. The cookie-name is the name string, and the cookie-value is the