jiebi/CodeConvo huggingface dataset:
Code change:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Related discussion:
text: 5.3.2. <del> All dependent streams are allocated an integer weight between 1 to </del> <ins> All dependent streams are allocated an integer weight between 1 and </ins> 256 (inclusive). Streams with the same parent SHOULD be allocated resources
Code change:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Related discussion:
text: A HeaderBlock. <del> Padding octets. </del> <ins> Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending and ignored when receiving. </ins> The HEADERS frame defines the following flags:
Code change:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Related discussion:
text: stream risks being ignored due to the peer having discarded priority state information for that stream. <ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.4. The RST_STREAM frame (type=0x3) allows for abnormal termination of a
Code change:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Related discussion:
text: . <ins> A RST_STREAM frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5. The SETTINGS frame (type=0x4) conveys configuration parameters that
Code change:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Related discussion:
text: . <ins> A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5.1. The payload of a SETTINGS frame consists of zero or more parameters,
Code change:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Related discussion:
text: frame toward the flow control window, if the receiver does not, the flow control window at sender and receiver can become different. <ins> A WINDOW_UPDATE frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.9.1. Flow control in HTTP/2 is implemented using a window kept by each
Code change:
For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.

Related discussion:
text: 4. <del> 4.1. </del> To limit the memory requirements on the decoder side, the dynamic table is constrained in size. <ins> 4.1. The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </ins> Protocols that use HPACK determine the maximum size of table that the encoder is permitted to use.  In HTTP/2, this value is determined by the SETTINGS_HEADER_TABLE_SIZE setting (see HTTP2).
Code change:
For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.

Related discussion:
text: dynamic table by setting a maximum size of 0, which can subsequently be restored. <del> The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </del> <ins> 4.3. </ins> Whenever the maximum size for the dynamic table is reduced, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size. <del> 4.3. </del> <ins> 4.4. </ins> Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the
Code change:
This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.

Related discussion:
text: The underlying transport has properties that do not meet minimum security requirements (see TLSUsage). <ins> The endpoint requires that HTTP/1.1 be used instead of HTTP/2. </ins> Unknown or unsupported error codes MUST NOT trigger any special behavior.  These MAY be treated by an implementation as being equivalent to
Code change:
This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.

Related discussion:
text: This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification <del> might provide a way to support this use case. </del> <ins> might provide a way to support this use case.  Alternatively, a server might use a ConnectionErrorHandler of type to request the client use a protocol which supports renegotiation. </ins> 9.2.2.
Code change:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Related discussion:
text: A header list is an ordered collection of header fields that are encoded jointly, and can contain duplicate header fields.  A <del> complete list of key-value pairs contained in a HTTP/2 header </del> <ins> complete list of key-value pairs contained in an HTTP/2 header </ins> block is a header list. A header field can be represented in encoded form either as a
Code change:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Related discussion:
text: HTTP/2 does not use the "Connection" header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT <del> generate a HTTP/2 message containing connection-specific header </del> <ins> generate an HTTP/2 message containing connection-specific header </ins> fields; any message containing connection-specific header fields MUST be treated as malformed.
Code change:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Related discussion:
text: . Pushed responses that are cacheable (see RFC7234) can be stored by <del> the client, if it implements a HTTP cache.  Pushed responses are </del> <ins> the client, if it implements an HTTP cache.  Pushed responses are </ins> considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open.
Code change:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Related discussion:
text: The DATA frame defines the following flags: <del> Bit 1 being set indicates that this frame is the last that the </del> <ins> Bit 0 being set indicates that this frame is the last that the </ins> endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 4 being set indicates that the Pad Length field and any </del> <ins> Bit 3 being set indicates that the Pad Length field and any </ins> padding that it describes is present. DATA frames MUST be associated with a stream.  If a DATA frame is
Code change:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Related discussion:
text: SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: <del> Bit 1 being set indicates that this frame acknowledges receipt and </del> <ins> Bit 0 being set indicates that this frame acknowledges receipt and </ins> application of the peer's SETTINGS frame.  When this bit is set, the payload of the SETTINGS frame MUST be empty.  Receipt of a SETTINGS frame with the ACK flag set and a length field value
Code change:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Related discussion:
text: The PING frame defines the following flags: <del> Bit 1 being set indicates that this PING frame is a PING response. </del> <ins> Bit 0 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.
Code change:
Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.

Related discussion:
text: connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher. <del> A client MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </del> <ins> An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </ins> renegotiation MUST occur prior to sending the connection preface.  A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.
Code change:
Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.

Related discussion:
text: This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification might provide a way to support this use case.  Alternatively, a <del> server might use a ConnectionErrorHandler of type </del> <ins> server might use an ErrorHandler of type </ins> to request the client use a protocol which supports renegotiation.
Code change:
As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.

Related discussion:
text: assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned <del> priority or become a dependency for other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </del> <ins> priority or become a parent of other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </ins> more flexible expressions of priority.  Idle streams that are made a <del> dependency are assigned a pri-default. </del> <ins> parent of another stream are assigned a pri-default. </ins> The retention of priority information for streams that are not counted toward the limit set by