jiebi/CodeConvo huggingface dataset:
Code change:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Related discussion:
text: 3.5. The control data for a response message consists of the status code. <del> The status code is encoded as a variable length integer, not a </del> <ins> The status code (HTTP) is encoded as a variable length integer, not a </ins> length-prefixed decimal string. The format of final response control data is shown in format-
Code change:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Related discussion:
text: 3.5.1. <del> Responses that include information status codes (see HTTP) are </del> <ins> Responses that include informational status codes (see HTTP) are </ins> encoded by repeating the response control data and associated header section until the final status code is encoded.
Code change:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Related discussion:
text: format-informational. A response message can include any number of informational responses <del> that precede a final status code.  These convey an information status code and a header block. </del> <ins> that precede a final status code.  These convey an informational status code and a header block. </ins> If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is
Code change:
Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.

Related discussion:
text: Header and trailer sections consist of zero or more field lines; see HTTP.  The format of a field section depends on whether the message <del> is known- or intermediate-length. </del> <ins> is known- or indeterminate-length. </ins> Each field line includes a name and a value.  Both the name and value are length-prefixed sequences of bytes.  The field name length is at
Code change:
Just a little more explanation. And .
Comment by NAME : I see that the talks about "final status code": and that explains why you called it "final" in , but I think you need to define why "final" is used in the "final response control data" when it first appear (so in ), or you can remove "final" in 3.5 and explain that only in 3.5.1.

Related discussion:
text: Responses that include informational status codes (see HTTP) are encoded by repeating the response control data and associated header <del> section until the final status code is encoded. </del> <ins> section until a final response control data is encoded.  The status code distinguishes between informational and final responses. </ins> The format of the informational response control data is shown in format-informational.
Code change:
Arguably a technical change, though as it is in a picture, so I want to highlight it. This is on top of , so just look at 5468983321b104de62b1aae8df8963ad1abd5fa9 if you want to see the "technical" change.

Related discussion:
text: 3.1. <del> A message that has a known length at the time of construction uses the format shown in format-known-length. </del> <ins> A request or response that has a known length at the time of construction uses the format shown in format-known-length. </ins> <del> That is, a known-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section with a length prefix, binary content with a length prefix, and a trailer section with a length prefix. </del> <ins> A known-length request consists of a framing indicator (framing), request control data (request-control), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding. </ins> <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. </del> <ins> A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) followed by response control data (response-control). </ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is
Code change:
Arguably a technical change, though as it is in a picture, so I want to highlight it. This is on top of , so just look at 5468983321b104de62b1aae8df8963ad1abd5fa9 if you want to see the "technical" change.

Related discussion:
text: 3.2. <del> A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: </del> <ins> A request or response that is constructed without encoding a known length for each section uses the format shown in format- indeterminate-length: </ins> <del> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del> <ins> An indeterminate-length request consists of a framing indicator (framing), request control data (request-control), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding. </ins> <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> <ins> An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) and response control data (response-control). </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be
Code change:
I had to read this several times to understand what parts of the sentence were replicated into the "or" part of the statement. Duplicating some words makes it a tiny bit more comprehensible, I think.
LGTM

Related discussion:
text: contains a digest value computed by applying a hashing algorithm to selected representation data (SEMANTICS).  Basing "Repr-Digest" on the selected representation makes it straightforward to apply it to <del> use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </del> <ins> use-cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </ins> "Content-Digest" and "Repr-Digest" support hashing algorithm agility. The "Want-Content-Digest" and "Want-Repr-Digest" fields allow endpoints to express interest in "Content-Digest" and "Repr-Digest" <del> respectively, and preference of algorithms in either. </del> <ins> respectively, and to express algorithm preferences in either. </ins> "Content-Digest" and "Repr-Digest" are collectively termed Integrity fields.  "Want-Content-Digest" and "Want-Repr-Digest" are
Code change:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Related discussion:
text: framing, which describes whether the message is a request or response and how subsequent sections are formatted; see framing. <del> For a response, any number of interim responses, each consisting of an informational status code and header section. </del> <ins> For a response, any number of informational responses, each consisting of an informational status code and header section. </ins> Control data.  For a request, this contains the request method and target.  For a response, this contains the status code.
Code change:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Related discussion:
text: for the semantics of repeated field names and rules for combining values. <ins> Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2). Field lines containing pseudo-fields MUST precede other field lines. A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields <del> allows a binary message to capture the content of a messages that are exchanged in a protocol context. </del> <ins> allows a binary message to capture messages that are exchanged in a protocol context. </ins> <del> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </del> <ins> Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </ins> 3.7.
Code change:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Related discussion:
text: 4. This document describes a number of ways that a message can be <del> invalid.  Invalid messages MUST NOT be processed except to log an error and produce an error response. </del> <ins> invalid.  Invalid messages MUST NOT be processed further except to log an error and produce an error response. </ins> The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error
Code change:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Related discussion:
text: This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in ex-bink- <del> request.  ex-bink-request view includes some of the text alongside to show that most of the content is not modified. </del> <ins> request.  ex-bink-request includes text alongside to show that most of the content is not modified. </ins> This example shows that the Host header field is not replicated in <del> the :authority field, as is required for ensuring that the request is reproduced accurately; see H2. </del> <ins> the ":authority" field, as is required for ensuring that the request is reproduced accurately; see H2. </ins> The same message can be truncated with no effect on interpretation. In this case, the last two bytes - corresponding to content and a
Code change:
Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm

Related discussion:
text: Some of these features are also absent in HTTP/2 and HTTP/3. Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control <del> data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> data rather than using pseudo-fields. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no
Code change:
... 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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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.
Code change:
-
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.

Related discussion:
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").
Code change:
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

Related discussion:
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> <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