jiebi/CodeConvo huggingface dataset:
Code change:
Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you

Related discussion:
text: 5.1. <del> The example HTTP/1.1 message in ex-request shows the content of a "message/http". </del> <ins> The example HTTP/1.1 message in ex-request shows the content in the "message/http" format. </ins> Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0a and 0x0d).  For simplicity and consistency, the content of
Code change:
Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you

Related discussion:
text: 7. <del> The message/http media type can be used to enclose a single HTTP </del> <ins> The "message/bhttp" media type can be used to enclose a single HTTP </ins> request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.
Code change:
…ng authentication if Erik is cool with it.
NAME
ETIMEDOUT NAME if you object please reopen.

Related discussion:
text: A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware of.  However, once a valid and authenticated commitment has been <del> received, clients SHOULD NOT use an unauthenticated alternative service.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services.  A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </del> <ins> received, clients SHOULD NOT use an alternative service without both reasonable assurances (see auth) and strong authentication.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services. A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </ins> 5.3.
Code change:
What does it mean for a client to send, for example, a CONNECT request in the binary message. Is that permitted or prohibited?
I don't think that it needs to be prohibited. It's just not going to do anything that makes any sense. Worth a note perhaps.
I guess it could work if the thing you're delivering the binary message to actually actions the CONNECT, exchanging tunneled bytes would just look like content.
You would need somewhere for those bytes to go. A valid CONNECT request doesn't include a body. It's nonsensical basically.

Related discussion:
text: Many of these same restrictions are shared by HTTP/2 H2 and HTTP/3 H3. <ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no purpose as these requests are used to affect protocol behavior, which this format cannot do without additional mechanisms. </ins> 7. The "message/bhttp" media type can be used to enclose a single HTTP
Code change:
The HTTP/2 rules are related to field value validation, so move them there. The rules about Connection fields are not necessary, but it won't hurt to be clearer.
the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (Section 8.1.1 of [H2]) as invalid; see Section 4. Those references are doing a lot of work -- but does it also include 8.2.2? I.e., are and friends allowed? It's ambiguous, because the text implies all things that make it malformed, but only points to one source.
No point duplicating that work, but I agree that it might be unclear as stated. Does this split make it clearer? I'll make a PR with those changes in context. (I think that the latter is consistent with what you and NAME are discussing on-list, though I need to spend a bit more time on understanding that.)
I think it does the job, indeed!

Related discussion:
text: For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see HTTP for a definition of <del> what is valid and invalid for handling of invalid messages. Field names and values MUST be constructed and validated according to the rules of H2.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (H2) as invalid; see invalid. </del> <ins> what is valid and invalid for handling of invalid messages.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed according to H2 as invalid; see invalid. </ins> The same field name can be repeated in multiple field lines; see HTTP for the semantics of repeated field names and rules for combining values. <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 allows a binary message to capture the content of a messages that are exchanged in a protocol context. </ins> 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
Code change:
The format is capable of capturing messages, but the design only really supports the expression of the semantics of valid messages. That makes it unsuitable for applications that need to know exactly what was put on the wire in a given protocol.
This document is going to be viewed by some as establishing the 'shape' of an HTTP message -- which is a good and perhaps necessary thing. However, some will be sad, because it doesn't suit some applications such as forensic preservation of messages, bot detection, debugging, faithful representation of HTTP/1, etc., due to transformations and loss of certain information (especially around headers). So it'd be good to set expectations early on (perhaps in the Introduction).
Good point. It's for semantics, not forensics and all that.

Related discussion:
text: an indefinite-length encoding enables efficient generation of messages where lengths are not known when encoding starts. <ins> This format is designed to convey the semantics of valid HTTP messages as simply and efficiently as possible.  It is not designed to capture all of the details of the encoding of messages from specific HTTP versions (MESSAGING, H2, H3).  As such, this format is unlikely to be suitable for applications that depend on an exact recording of the encoding of messages. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Code change:
The original framing might have implied that they can't be sent, where it's just that they are the same as anything else.
In s 6: This is just a bit weird -- some may read it to mean that these messages can't be conveyed in this format.

Related discussion:
text: framing of responses that depends on the corresponding request (such as HEAD) or the value of the status code (such as 204 or <del> 304) </del> <ins> 304); these responses use the same framing as all other messages </ins> Some of these features are also absent in HTTP/2 and HTTP/3.
Code change:
For the avoidance of doubt. This makes encoding easier if you don't care about wasting a few bytes.
The binary messages draft uses QUIC variable-length integers. Those allow encoding numbers multiple ways (for example 42 can be encoded minimally as 0x2A but also non-minimally as 0x402A). The draft should clarify whether using non-minimal encoding is allowed or not.
Thanks!

Related discussion:
text: Optional padding.  Any amount of zero-valued bytes. All lengths and numeric values are encoded using the variable-length <del> integer encoding from QUIC. </del> <ins> integer encoding from QUIC.  Integer values do not need to be encoded on the minimum number of bytes necessary. </ins> 3.1.
Code change:
by using a citation rather than a redundant and wrong statement. by removing the minimum length (zero is totally fine).
The Known-Length Messages section states that whereas the Header and Trailer Field Lines section allows empty field values. Which is it?
Editorial error on my part. Someone pointed out that fields can have empty values (yet another feature of the protocol that is weird and unnecessary). I fixed it one place, but not the other. Thanks for noticing.
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: different structure; see informational. Fields in the header and trailer sections consist of a length- <del> prefixed name and length-prefixed value.  Both name and value are sequences of bytes that cannot be zero length. </del> <ins> prefixed name and length-prefixed value; see fields. </ins> The format allows for the message to be truncated before any of the length prefixes that precede the field sections or content.  This
Code change:
Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks

Related discussion:
text: prefixed name and length-prefixed value; see fields. The format allows for the message to be truncated before any of the <del> length prefixes that precede the field sections or content.  This reduces the overall message size.  A message that is truncated at any other point is invalid; see invalid. </del> <ins> length prefixes that precede the field sections or content; see padding. </ins> The variable-length integer encoding means that there is a limit of 2^62-1 bytes for each field section and the message content.
Code change:
Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks

Related discussion:
text: indeterminate-length, it can only appear in response messages. Indeterminate-length messages can be truncated in a similar way as <del> known-length messages.  Truncation occurs after the control data, or after the Content Terminator field that ends a field section or sequence of content chunks.  A message that is truncated at any other point is invalid; see invalid. </del> <ins> known-length messages; see padding. </ins> Indeterminate-length messages use the same encoding for field lines as known-length messages; see fields.
Code change:
Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks

Related discussion:
text: it is unlikely to be a practical limitation.  There is no limit to the size of content in an indeterminate length message. <del> Omitting content by truncating a message is only possible if the content is zero-length. </del> 3.8. Messages can be padded with any number of zero-valued bytes.  Non-
Code change:
Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks

Related discussion:
text: Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes. <ins> Truncation can be used to reduce the size of messages that have no data in trailing field sections or content.  If the trailers of a message is empty, it MAY be omitted by the encoder in place of adding a length field equal to zero.  An encoder MAY omit empty content in the same way if the trailers are also empty.  A message that is truncated at any other point is invalid; see invalid. Decoders MUST treat missing truncated fields as equivalent to having been sent with the length field sent to zero. </ins> Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as zero-length part, which is semantically equivalent to the part being absent.
Code change:
The diagram resulted in a few double-takes that might be helped by a little bit of a note pointing this out.
I suspect that requests do not carry the Known-Length Informational Response field (otherwise how do you know how many of them there are?) but that should be spelled out explicitly. I'd suggest creating a different diagram for known-length request vs known-length responses to make this easier to reason about, and same for indeterminate length
I think the optionality is supposed to be indicated by the three trailing dots . I admit to doing a double-take on this during my initial review, similar to David's question. It's optional for a server, sure, but it's never optional for a request just wrong. I agree that separate diagrams would help, at the minor cost of some page space.

Related discussion:
text: prefix. Response messages that contain informational status codes result in a <del> different structure; see informational. </del> <ins> 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> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.
Code change:
The diagram resulted in a few double-takes that might be helped by a little bit of a note pointing this out.
I suspect that requests do not carry the Known-Length Informational Response field (otherwise how do you know how many of them there are?) but that should be spelled out explicitly. I'd suggest creating a different diagram for known-length request vs known-length responses to make this easier to reason about, and same for indeterminate length
I think the optionality is supposed to be indicated by the three trailing dots . I admit to doing a double-take on this during my initial review, similar to David's question. It's optional for a server, sure, but it's never optional for a request just wrong. I agree that separate diagrams would help, at the minor cost of some page space.

Related discussion:
text: value, and a trailer section that is terminated by a zero value. Response messages that contain informational status codes result in a <del> different structure; see informational. </del> <ins> 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> Indeterminate-length messages can be truncated in a similar way as known-length messages.  Truncation occurs after the control data, or
Code change:
A combined "field value" is a term that HTTP defines, but we didn't link to that. Also, the structure of this paragraph was a little more terse than it needed to be.
Security Considerations state: but the Header and Trailer Field Lines section states: The same field name can be repeated in multiple field lines; see Section 5.2 of HTTP for the semantics of repeated field names and rules for combining values. This leaves me confused, why would it be necessary to produce a combined value if repeated field names are allowed?

Related discussion:
text: arise from receiving large messages, particularly those with large numbers of fields. <del> The format is designed to allow for minimal state when translating for use with HTTP proper.  However, producing a combined value for fields, which might be necessary for the "Cookie" field when translating this format (like HTTP/1.1 MESSAGING), can require the commitment of resources.  Implementations need to ensure that they aren't subject to resource exhaustion attack from a maliciously crafted message. </del> <ins> Implementations need to ensure that they aren't subject to resource exhaustion attack from a maliciously crafted message.  Overall, the format is designed to allow for minimal state when processing messages.  However, producing a combined field value (HTTP) for fields might require the commitment of resources.  In particular, combining might be necessary for the "Cookie" field when translating this format for use in other contexts, such as use in an API or translation to HTTP/1.1 MESSAGING, where the recipient of the field might not expect multiple values. </ins> 9.
Code change:
: These rules do not permit whitespace between a semicolon and a parameter, which was probably intended (judging from the examples and from similar rules elsewhere in HTTP). They should be rewritten as follows: and the import of the rule from RFC 7230 should be noted in the preceding text (“The "Encryption" header field uses the extended ABNF syntax . . .” and similarly for ).
Thanks for picking this up.

Related discussion:
text: how those content encoding(s) can be removed. The "Encryption" header field uses the extended ABNF syntax defined <del> in Section 1.2 of RFC7230 and the "parameter" rule from </del> <ins> in Section 1.2 of RFC7230 and the "parameter" and "OWS" rules from RFC7231. </ins> If the payload is encrypted more than once (as reflected by having multiple content-codings that imply encryption), each application of
Code change:
: These rules do not permit whitespace between a semicolon and a parameter, which was probably intended (judging from the examples and from similar rules elsewhere in HTTP). They should be rewritten as follows: and the import of the rule from RFC 7230 should be noted in the preceding text (“The "Encryption" header field uses the extended ABNF syntax . . .” and similarly for ).
Thanks for picking this up.

Related discussion:
text: material used in the Encryption header field. The Crypto-Key header field uses the extended ABNF syntax defined in <del> Section 1.2 of RFC7230 and the "parameter" rule from RFC7231. </del> <ins> Section 1.2 of RFC7230 and the "parameter" and "OWS" rules from RFC7231. </ins> The "keyid" parameter corresponds to the "keyid" parameter in the Encryption header field.