jiebi/CodeConvo huggingface dataset:
Code change:
no normative text in security considerations.
no normative statements in security considerations
Separately, this could be read to imply that a TCP checksum is sufficient. I'm not enthusiastic about that, URL Originally posted by NAME in URL In reply, I said
This has been slightly modified by ... TLS can't probably be normative, but people already knows...

Related discussion:
text: consumes the resources of both endpoints.  See also digest-and- content-location. <del> Digest fields SHOULD always be used over a connection that provides integrity at the transport layer that protects HTTP fields. A "Representation-Digest" field using NOT RECOMMENDED hashing algorithms SHOULD NOT be used in signatures. Using signatures to protect the checksum of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </del> <ins> Signatures are likely to be deemed an adversarial setting when applying Integrity fields; see algorithms.  Using signatures to protect the checksum of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </ins> Any mangling of digest fields, including de-duplication of representation-data-digest values or combining different field values
Code change:
simplifies IANA field registration section obsolete Digest
Thanks for this, it's almost there. I suggest we just have two sections that ask IANA to do things directly, rather than giving any prelude to those instructions.

Related discussion:
text: 7.1. <ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS) according to the table below: 7.2. </ins> This memo sets this specification to be the establishing document for the Hash Algorithms for HTTP Digest Fields [2] registry defined in algorithms.
Code change:
simplifies IANA field registration section obsolete Digest
Thanks for this, it's almost there. I suggest we just have two sections that ask IANA to do things directly, rather than giving any prelude to those instructions.

Related discussion:
text: IANA is asked to initialize the registry with the entries in iana- hash-algorithm-table. <del> 7.2. This section registers the "Representation-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Representation-Digest" Status: permanent Specification document(s): representation-digest of this document 7.3. This section registers the "Content-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Content-Digest" Status: permanent Specification document(s): content-digest of this document 7.4. This section registers the "Want-Representation-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Want-Representation-Digest" Status: permanent Specification document(s): want-fields of this document 7.5. This section registers the "Want-Content-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Want-Content-Digest" Status: permanent Specification document(s): want-fields of this document </del> 8.  References 8.1.  URIs
Code change:
Includes some new text and several small cleanups.
did you forget to merge it?
Sorry, there was ice cream cake and I got distracted
Some header field values are case-insensitive, in whole or in part. The canonicalization rules do not account for this, thus a case change to a covered header field value causes verification to fail.
While I'd just put a warning on that, it would be great to have some examples/use cases for that.
Intermediaries are permitted to strip comments from the header field value, and consolidate related sequences of entries. The canonicalization rules do not account for these changes, and thus they cause signature verification to fail if the header is signed. At the very least, guidance on signing or not signing headers needs to be included.
Let's add a paragraph with some caveats and header examples.

Related discussion:
text: The resulting string is the canonicalized component value. <ins> Note that some HTTP fields have values with multiple valid serializations that have equivalent semantics.  Applications signing and processing such fields MUST consider how to handle the values of such fields to ensure that the signer and verifier can derive the same value, as discussed in security-field-values. </ins> Following are non-normative examples of canonicalized values for header fields, given the following example HTTP message fragment:
Code change:
Includes some new text and several small cleanups.
did you forget to merge it?
Sorry, there was ice cream cake and I got distracted
Some header field values are case-insensitive, in whole or in part. The canonicalization rules do not account for this, thus a case change to a covered header field value causes verification to fail.
While I'd just put a warning on that, it would be great to have some examples/use cases for that.
Intermediaries are permitted to strip comments from the header field value, and consolidate related sequences of entries. The canonicalization rules do not account for these changes, and thus they cause signature verification to fail if the header is signed. At the very least, guidance on signing or not signing headers needs to be included.
Let's add a paragraph with some caveats and header examples.

Related discussion:
text: RFC8792 due to limitations in the document format that strips trailing spaces from diagrams. <ins> Any HTTP field component identifiers MAY have the following parameters in specific circumstances. </ins> 2.1.1. If value of the the HTTP field in question is a structured field
Code change:
I missed this from NAME but it's a point well-taken. Not defining this was sloppy.
This was buried inside which was closed so I'm opening a new issue. The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? It would really help if this draft defined every single field it declares.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks

Related discussion:
text: content with a length prefix, and a trailer section with a length prefix. <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 the number of bytes in the field section or content. </ins> 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,
Code change:
I missed this from NAME but it's a point well-taken. Not defining this was sloppy.
This was buried inside which was closed so I'm opening a new issue. The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? It would really help if this draft defined every single field it declares.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks

Related discussion:
text: 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. <ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block.  The Chunk Length is encoded as a variable-length integer. Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field.  An Indeterminate-Length Field Section ends with a Content Terminator field.  The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0. </ins> 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-
Code change:
S 3.6 says that extension pseudo header MAY be included but they have to appear before other field lines. An easy detail to miss buried in HTTP/2 is the requirement does that also apply here?
LGTM thanks

Related discussion:
text: control 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 <del> defined by protocol extensions MAY be included.  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> 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> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no
Code change:
If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.

Related discussion:
text: 2.2.9. If a request target URI uses HTML form parameters in the query string <del> as defined in HTMLURL, the "@query-params" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components. Single named parameters MAY occur in any order in the covered components. </del> <ins> as defined in HTMLURL, the "@query-param" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. </ins> The component value of a single named parameter is the the "valueString" of the named query parameter defined by HTMLURL, which
Code change:
If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.

Related discussion:
text: RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. <del> If used in a related-response, the "@query-params" component </del> <ins> If used in a related-response, the "@query-param" component </ins> identifier refers to the associated component value of the request that triggered the response message being signed.
Code change:
If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.

Related discussion:
text: need to be signed, avoiding problematic components.  For example, a web application framework that relies on rewriting query parameters might avoid use of the "@query" content identifier in favor of sub- <del> indexing the query value using "@query-params" content identifier </del> <ins> indexing the query value using "@query-param" content identifier </ins> instead. Some components are expected to be changed by intermediaries and
Code change:
"The record starts and ends on multiples of the record size" sounds like a tautology.

Related discussion:
text: A consequence of this record structure is that range requests RFC7233 and random access to encrypted payload bodies are possible at the granularity of the record size.  However, without data from adjacent <del> ranges, partial records cannot be used.  Thus, it is best if records start and end on multiples of the record size, plus the 16 octet authentication tag size. </del> <ins> ranges, partial records cannot be used.  Thus, it is best if range requests start and end on multiples of the record size, plus the 16 octet authentication tag size. </ins> 3.
Code change:
NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!

Related discussion:
text: 1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP2 which is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del> <ins> to HTTP/2 HTTP/2 which is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.
Code change:
NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!

Related discussion:
text: server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 </del> <ins> to those in HTTP/2 as defined RFC8441.  HTTP/3 requires that HTTP/3 </ins> settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.