jiebi/CodeConvo huggingface dataset:
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: The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </del> <ins> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </ins> 4.
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: 5. This document registers a new setting in the "HTTP/3 Settings" <del> registry (HTTP3). </del> <ins> registry (HTTP/3). </ins>
Code change:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Related discussion:
text: 1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP/2 that 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. </del> <ins> to HTTP/2 HTTP2 that 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. </ins> 2.
Code change:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

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 in RFC8441.  HTTP/3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del> <ins> to those in HTTP/2 as defined in RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.
Code change:
NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)

Related discussion:
text: The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </del> <ins> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </ins> 4.
Code change:
Typi fix
I had to read that three times to spot your change. Something about that text blinded me to that.

Related discussion:
text: Some of these features are also absent in HTTP/2 and HTTP/3. <del> Unlike HTTP/2 and HTTP/3, this format uses a a fixed format for 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 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> Unlike HTTP/2 and HTTP/3, this format uses a fixed format for 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 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:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: For more advanced use-cases, the "Repr-Digest" request and response header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to <del> "selected representation data" (SEMANTICS).  Basing "Repr-Digest" on </del> <ins> selected representation data (SEMANTICS).  Basing "Repr-Digest" on </ins> the selected representation makes it straightforward to apply it to use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial
Code change:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: integrity.  It also coined the term "instance" and "instance manipulation" in order to explain concepts that are now more universally defined, and implemented, as HTTP semantics such as <del> "selected representation data" (SEMANTICS). </del> <ins> selected representation data (SEMANTICS). </ins> Experience has shown that implementations of RFC3230 have interpreted the meaning of "instance" inconsistently, leading to interoperability
Code change:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: The "Repr-Digest" HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm <del> applied to the entire "selected representation data" (see SEMANTICS). </del> <ins> applied to the entire selected representation data (see SEMANTICS). </ins> Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests
Code change:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: representation concepts, several examples are provided in resource- representation. <del> When a message has no "representation data" it is still possible to assert that no "representation data" was sent by computing the digest </del> <ins> When a message has no representation data it is still possible to assert that no representation data was sent by computing the digest </ins> on an empty string (see usage-in-signatures). "Repr-Digest" is a "Dictionary" (see STRUCTURED-FIELDS) where each:
Code change:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: 6.1. This document specifies a data integrity mechanism that protects HTTP <del> "representation data" or content, but not HTTP header and trailer </del> <ins> representation data or content, but not HTTP header and trailer </ins> fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against
Code change:
Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that

Related discussion:
text: 6.2. <del> Integrity fields can help detect "representation data" or content </del> <ins> Integrity fields can help detect representation data or content </ins> modification due to implementation errors, undesired "transforming proxies" (see SEMANTICS) or other actions as the data passes across multiple hops or system boundaries.  Even a simple mechanism for end- <del> to-end "representation data" integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </del> <ins> to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could
Code change:
try to say that for multiple post-handshake client certificate authentications, only use the last one (to
TLS 1.3 post-handshake authentication enables the use of multiple client authentications. The draft probably needs to address this. Firstly, the proxy could be smart enough to know which certificate applies. After all, it needs to know how and when to ask for a certificate. If it is that smart, we don't have a problem. If not, then... For , this is easy. If there are multiple certificates and the reverse proxy doesn't know which to include, it can include all of them. It's easy enough to add extra values. For this is less easy. There would be no way to distinguish which intermediate related to which end-entity certificate if you just added them all. I don't think that's fatal though. Chain building for validation always has to deal with certificates that don't do anything, so maybe we can just dump them all in there and let the back-end server sort them out. In terms of actions, we can say something like:
The draft currently , which precludes multiple values/instances. I am very reluctant to change that in support of something that rarely if ever happens in practice (it would mean HTTP/1.1 with multiple TLS 1.3 post-handshake authentications or post-handshake authentication(s) after a client cert authenticated handshake). Could we instead just say the first/last one is used? Then it's predictable/defined should it ever happen. Or declare it out of scope. Existing related text from URL is copied here: >HTTP/2 restricts TLS 1.2 renegotiation ( of ]) and prohibits TLS 1.3 post-handshake authentication ]. However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 ] where the server decides whether to request a client certificate based on the HTTP request. HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document.
I could live with picking the last in the absence of information that might allow for another to be selected. But what harm is there in using a list?
Makes it all more complicated b/c everything then needs to treat it as a list and reason about it being a list. The value in typing something as what it is seems self-evident so I'm at a bit of a lose as to how else to answer that question.
WFM.

Related discussion:
text: application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. <ins> With post-handshake authentication there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection, in which case only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein. </ins> 2.
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: a known-length encoding includes length prefixes for all major message components; and <del> an indefinite-length encoding enables efficient generation of </del> <ins> an indeterminate-length encoding enables efficient generation of </ins> messages where lengths are not known when encoding starts. This format is designed to convey the semantics of valid HTTP
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: content with a length prefix, and a trailer section with a length prefix. <del> 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. </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. <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, not including the length field itself. </ins> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.
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: A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: <del> That is, an indeterminate length 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> 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. 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. </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be
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: distinguishes it from the Name Length field, which cannot contain a value of 0. <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> Indeterminate-length messages can be truncated in a similar way as known-length messages; see padding.