jiebi/TextFlow huggingface dataset:
Original text:
Structured Field (a Dictionary), respectively. In each case, cookie names are Tokens.  Their values are Strings, <del> unless they can be represented accurately and unambiguously using the textual representation of another structured types (e.g., an Integer or Decimal). </del>  Set-Cookie parameters map to Parameters on the appropriate SF-Set- Cookie member, with the parameter name being forced to lowercase.

Reviewer comments:
... and apparently some other stuff.
Should we recognise e.g., binary content in cookie values? If so, how?
Do you mind expanding on what you mean?
This is for the retrofit spec's cookie mapping](URL). Since many cookie's payloads are base64, it seems like it'd be beneficial to figure out a way to carry them as binary. I've been meaning to start a discussion with the cookie authors about this section of the spec generally to a) make sure it's a good idea and b) it's correct / doesn't cause problems. PTAL if you have time.
Maybe the right thing to do here is to introduce a new parameter that indicates the type of the value.
... except parameters aren't available on Cookie; just Set-Cookie. hmm.
Perhaps the most we can do is to say that the SF-cookie headers can have a value in any type, but they get mapped to the string value in "normal" headers. That way you can automatically convert SF-cookie to cookie, but not the other way around. The only alternative I see is to carry the type information in a separate header, which is not great.

Revised text:
Structured Field (a Dictionary), respectively. In each case, cookie names are Tokens.  Their values are Strings,  <ins> unless the value can be successfully parsed as the textual representation of another, bare Item structured type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). </ins> Set-Cookie parameters map to Parameters on the appropriate SF-Set- Cookie member, with the parameter name being forced to lowercase.
Original text:
that use different grammatical notations than this document (which uses ABNF from RFC5234).  The semantics of the cookie-value are not defined by this document. To maximize compatibility with user agents, servers that wish to

Reviewer comments:
Cookie attribute names are case insensitive, this PR adds a note saying as much.
The grammar implies that set-cookie attribute names are case insensitive (because ABNF strings are), and the parsing algorithms say that they're case-insensitive, but I suspect many people may not realise this, because they're so often seen in CamelCase. Could we add a small statement to the Set-Cookie syntax section pointing this out?
It's also worth having a variety of styles in the examples to illustrate this.

Revised text:
that use different grammatical notations than this document (which uses ABNF from RFC5234). <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> The semantics of the cookie-value are not defined by this document. To maximize compatibility with user agents, servers that wish to
Original text:
Therefore, applications should not rely on specific labels being present, and applications should not put semantic meaning on the <del> labels themselves.  Instead, additional signature parmeters can be </del>  used to convey whatever additional meaning is required to be attached to and covered by the signature.

Reviewer comments:
There are a few cases where the word is used. From the context, it appears that the intended word is .
Thanks! I have no idea why my spellcheck didn't catch those, and I appreciate it.

Revised text:
Therefore, applications should not rely on specific labels being present, and applications should not put semantic meaning on the  <ins> labels themselves.  Instead, additional signature parameters can be </ins> used to convey whatever additional meaning is required to be attached to and covered by the signature.
Original text:
"content" in this document are to be interpreted as described in RFC9110.  Hashing algorithm names respect the casing used in their definition document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c").

Reviewer comments:
-
LGTM modulo nit
NAME 8972 Simple Two-Way Active Measurement Protocol Optional Extensions or URL line wrapping? Since 8792 is used in examples, dunno if that's normative but it's ok.
:-) Typo fixed. In any case, we need to reference it (IMHO). I would also suggest to avoid the escaping when not needed.

Revised text:
"content" in this document are to be interpreted as described in RFC9110. <ins> This document uses the line folding strategies described in FOLDING. </ins> Hashing algorithm names respect the casing used in their definition document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c").
Original text:
inputs.  However, the canonicalized component value is never parsed by the message signature process, merely used as part of the signature base in create-sig-input.  Even so, caution needs to be <del> taken when including such fields in signatures, see security-non-list for more discussion of this issue. </del>  If the combined value is not available for a given header, the following algorithm will produce canonicalized results for an

Reviewer comments:
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and

Revised text:
inputs.  However, the canonicalized component value is never parsed by the message signature process, merely used as part of the signature base in create-sig-input.  Even so, caution needs to be  <ins> taken when including such fields in signatures, and the "bs" parameter defined in http-header-byte-sequence provides a method for wrapping such problematic fields.  See security-non-list for more discussion of this issue. </ins> If the combined value is not available for a given header, the following algorithm will produce canonicalized results for an
Original text:
Dictionary is identified by using the parameter "key" and the Dictionary member key as a String value.  An individual member value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in STRUCTURED-FIELDS on the "member_value" and its parameters, without

Reviewer comments:
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and

Revised text:
Dictionary is identified by using the parameter "key" and the Dictionary member key as a String value. <ins> Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> An individual member value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in STRUCTURED-FIELDS on the "member_value" and its parameters, without
Original text:
base by adding the "req" parameter to the component identifier. This parameter can be applied to both HTTP fields and derived <del> components with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message. </del>  Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same

Reviewer comments:
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and

Revised text:
base by adding the "req" parameter to the component identifier. This parameter can be applied to both HTTP fields and derived  <ins> components that target the request, with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied. </ins> Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same
Original text:
Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such <del> values. </del>  Specifically, the Set-Cookie field COOKIE defines an internal syntax that does not conform to the List syntax in STRUCTURED-FIELDS.  In

Reviewer comments:
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and

Revised text:
Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such  <ins> values.  Signers can make use of the "bs" parameter to armor such fields, as described in http-header-byte-sequence. </ins> Specifically, the Set-Cookie field COOKIE defines an internal syntax that does not conform to the List syntax in STRUCTURED-FIELDS.  In
Original text:
This document is structured as follows: <del> content-digest defines the Content-Digest request and response header and trailer field, </del>  <del> representation-digest defines the Repr-Digest request and response header and trailer field, </del>  <del> want-fields defines the Want-Repr-Digest and Want-Content-Digest request and response header and trailer field, </del>  <del> algorithms describes algorithms and their relation to the fields defined in this document, </del>  <del> state-changing-requests details computing representation digests, </del>  <del> examples-unsolicited and examples-solicited provide examples of using Repr-Digest and Want-Repr-Digest. </del>  1.2.

Reviewer comments:
Section 1.1 is currently a bit confusing, because it leaves out sections, and does not present them in order (likely the cause of a recent re-org).
NAME do we need it?
it should either make sense, or should be removed.
NAME if it's not required, I think that the document is fine without.
mnot asked us to add one a while back, which I think helped at that point. Editorial changes in the meantime have had an effect though, so I tried to add some colour to the structure in URL Preview at URL The intention is that people can launch of from here to focus on bits they might need, like the field definitions or example. Since security and IANA sections are standard, mentioning them seems superfluous. If the opinion is that the proposal doesn't help, let's just remove the section.

Revised text:
This document is structured as follows:  <ins> New request and response header and trailer field definitions. </ins>  <ins> content-digest (Content-Digest), </ins>  <ins> representation-digest (Repr-Digest), and </ins>  <ins> want-fields (Want-Content-Digest and Want-Repr-Digest). </ins>  <ins> Considerations specific to representation data integrity. </ins>  <ins> state-changing-requests (State-changing requests), digest-and-content-location (Content-Location), resource-representation contains worked examples of Representation data in message exchanges, and examples-unsolicited and examples-solicited contain worked examples of Repr-Digest and Want-Repr-Digest fields in message exchanges. algorithms bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries. </ins> 1.2.
Original text:
If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows. <del> If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av. </del>  If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av. <del> Let delta-seconds be the attribute-value converted to an integer. </del>  Let cookie-age-limit be the maximum age of the cookie (which SHOULD be 400 days or less, see attribute-max-age).

Reviewer comments:
Contains the following changes: Skip parsing the attribute on empty value. Skip parsing the attribute when given Max-Age=- Add mention of "base 10" as guidance for implementers parsing integers from Max-Age. Regarding browser interop: Skip parsing aligns on Safari behavior and against Chrome and Firefox, which will default to session lifetime when any invalid Max-Age attribute is found (based on manual testing, it's difficult to test this with WPT at the moment, see ).

Revised text:
If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows.  <ins> If the attribute-value is empty, ignore the cookie-av. If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av. </ins> If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.  <ins> Let delta-seconds be the attribute-value converted to a base 10 integer. </ins> Let cookie-age-limit be the maximum age of the cookie (which SHOULD be 400 days or less, see attribute-max-age).
Original text:
the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. <del> Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.  Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. </del>  3.

Reviewer comments:
Editorial, since this is merely restating locally what was previously incorporated by reference.
In draft 00 it says: >The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ]. The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. I think this is the text as it was, before we ran HTTP/3 and HTTP/2 through the process. I think there's some room for editorial improvements to avoid the guesswork. Not least because HTTP/2 Origin has an errata on the payload definition (URL). My suggestion is to just admit defeat and define the whole frame like we do in HTTP/3 or ext priorities, something like Then we can say something like the semantics of the HTTP/3 ORIGIN frame payload are the same as those of the HTTP/2 ORIGIN frame, modulo the differences already described (control streams and whatnot).

Revised text:
the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs.  <ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. 2.1. The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </ins> 3.
Original text:
3.3.5.  To sign using this algorithm, the signer applies the "Ed25519" algorithm defined in RFC8032 with the signer's private signing key and the signature base (create-sig-input).  The signature base is

Reviewer comments:
Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.

Revised text:
3.3.5. <ins> To sign using this algorithm, the signer applies the "ECDSA" algorithm defined in FIPS186-4 using curve P-384 with the signer's private signing key and the signature base (create-sig-input).  The hash SHA-384 RFC6234 is applied to the signature base to create the digest content to which the digital signature is applied, ("M").  The signature algorithm returns two integer values, "r" and "s".  These are both encoded as big-endian unsigned integers, zero-padded to 48-octets each.  These encoded values are concatenated into a single 96-octet array consisting of the encoded value of "r" followed by the encoded value of "s".  The resulting concatenation of "(r, s)" is byte array of the HTTP message signature output used in sign. To verify using this algorithm, the verifier applies the "ECDSA" algorithm defined in FIPS186-4 using the public key portion of the verification key material and the signature base re-created as described in verify.  The hash function SHA-384 RFC6234 is applied to the signature base to create the digest content to which the signature verification function is applied, ("M").  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  This value is a 96-octet array consisting of the encoded values of "r" and "s" concatenated in order.  These are both encoded in big-endian unsigned integers, zero-padded to 48-octets each.  The resulting signature value "(r, s)" is used as input to the signature verification function.  The results of the verification function indicate if the signature presented is valid. Note that the output of ECDSA algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. Use of this algorithm can be indicated at runtime using the "ecdsa- p384-sha384" value for the "alg" signature parameter. 3.3.6. </ins> To sign using this algorithm, the signer applies the "Ed25519" algorithm defined in RFC8032 with the signer's private signing key and the signature base (create-sig-input).  The signature base is