jiebi/CodeConvo huggingface dataset:
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: 4.4. <del> 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 dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </del> <ins> Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </ins> If the representation of the added entry references the name of an entry in the dynamic table, the referenced name is cached prior to
Code change:
Kathleen Moriarty's IESG review noted some confusion that I think derived from the use of the word "prohibited" in relation to the cipher suite black list.

Related discussion:
text: 9.2.2. A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher <del> suites that are listed in BadCipherSuites. </del> <ins> suites that are listed in the BadCipherSuites. </ins> Endpoints MAY choose to generate a ConnectionErrorHandler of type <del> if one of the prohibited cipher suites are negotiated.  A deployment that chooses to use a prohibited cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </del> <ins> if one of the cipher suites from the black list are negotiated.  A deployment that chooses to use a black-listed cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </ins> Implementations MUST NOT generate this error in reaction to the <del> negotiation of a cipher suite that is not in the prohibited list. Consequently, when clients offer a cipher suite that is not prohibited, they have to be prepared to use that cipher suite with </del> <ins> negotiation of a cipher suite that is not on the black list. Consequently, when clients offer a cipher suite that is not on the black list, they have to be prepared to use that cipher suite with </ins> HTTP/2. <del> The effect of prohibiting these cipher suites is that TLS 1.2 deployments could have non-intersecting sets of available cipher suites, since the prohibited set includes the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </del> <ins> The black list includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non- intersecting sets of permitted cipher suites.  To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </ins> Note that clients might advertise support of cipher suites that are <del> prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2 and support only prohibited cipher suites.  This allows servers to select HTTP/1.1 with a cipher suite that is prohibited for HTTP/2.  However, this can result in HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. </del> <ins> on the black list in order to allow for connection to servers that do not support HTTP/2.  This allows servers to select HTTP/1.1 with a cipher suite that is on the HTTP/2 black list.  However, this can result in HTTP/2 being negotiated with a black-listed cipher suite if the application protocol and cipher suite are independently selected. </ins> 10.
Code change:
Proposal to replace . I think that this is a little clearer this way. Also, it's strange that this was not added earlier, but then sometimes the most obvious things get missed. cc NAME
So I'm not seeing how the new sentence is any different than this one two paragraphs below: A receiver MUST terminate the connection with a connection error of type COMPRESSIONERROR if it does not decompress a header block. My chief concern (merely editorial) is that HPACK consistently uses the phrase "decoding error" whereas here we are using the phrase "decompress." I think it good to make clear that any and all decoding errors MUST result in connection errors of type COMPRESSIONERROR. Picky, I know. ;-)
I think that Martin's proposal tries to specifically address your concern. The sentence two paragraphs below address the case of an endpoint deciding for whatever reason not to decompress a header block: this also has to result in a COMPRESSION_ERROR. So I think that both are useful.
Ahhh - thanks NAME Makes perfect sense and I agree.

Related discussion:
text: frame has the END_HEADERS flag set. Header compression is stateful.  One compression context and one <del> decompression context is used for the entire connection.  Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </del> <ins> decompression context is used for the entire connection.  A decoding error in a header block MUST be treated as a ConnectionErrorHandler of type . Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </ins> or
Code change:
Fixes for those things that were obviously busted. Which (I hope) addresses the comments, with one exception (Richard's discuss contained suggested edits that should clear that one up).

Related discussion:
text: frame. <del> The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is assigned pri-default.  Stream 1 is implicitly half closed from the client toward the server, since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </del> <ins> The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers) with pri-default. Stream 1 is implicitly "half closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </ins> 3.2.1.
Code change:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Related discussion:
text: Either the client or server of the connection. <del> The smallest unit of communication, each containing a frame header. </del> <ins> The smallest unit of communication within an HTTP/2.0 session, consisting of a header and a variable-length sequence of bytes structured according to the frame type. </ins> A complete sequence of frames.
Code change:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Related discussion:
text: An error on the HTTP/2.0 session. <del> A bi-directional flow of bytes across a virtual channel within the HTTP/2.0 session. </del> <ins> A bi-directional flow of frames across a virtual channel within the HTTP/2.0 session. </ins> An error on the individual HTTP/2.0 stream. 2. <del> Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes.  An HTTP/2.0-capable client is therefore required to discover whether the upstream server (including intermediaries) supports HTTP/2.0. </del> <ins> HTTP/2.0 uses the same "http:" and "https:" URI schemes used by HTTP/1.1.  As a result, implementations processing requests for a target resource URIs like "http://example.org/foo" or "https://example.com/bar" are required to first discover whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.0. </ins> <del> Different discovery mechanisms are defined for "http:" and "https:" URIs.  Discovery for "http:" URIs is described in discover-http; discovery for "https:" URIs is described in discover-https. </del> <ins> The means by which support for HTTP/2.0 is determined is different for "http" and "https" URIs.  Discovery for "https:" URIs is described in discover-https.  Discovery for "http" URIs is described here. </ins> 2.1.
Code change:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Related discussion:
text: 3.1. <del> The HTTP/2.0 session runs atop TCP (RFC0793).  The client is the TCP connection initiator. </del> <ins> The HTTP/2.0 session is an Application Level protocol running on top of a TCP connection (RFC0793).  The client is the TCP connection initiator. </ins> HTTP/2.0 connections are persistent.  That is, for best performance, <del> it is expected that clients will not close connections until the user navigates away from all Web pages referencing a connection, or until the server closes the connection.  Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections if necessary.  When either endpoint closes the transport- level connection, it MUST first send a GOAWAY frame so that the endpoints can reliably determine if messages were processed beforehand. </del> <ins> it is expected a clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page), or until the server closes the connection. Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level TCP connection, the terminating endpoint MUST first send a GOAWAY frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 3.2. <del> The first data sent on an HTTP/2.0 session - after opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake - is a session header. The session header provides a final confirmation that both peers agree to use the HTTP/2.0 protocol.  The SETTINGS frame ensures that client or server configuration is known as quickly as possible. </del> <ins> Upon establishment of a TCP connection and determination that HTTP/2.0 will be used by both peers to communicate, each endpoint MUST send a session header as a final confirmation and to establish the default parameters for the HTTP/2.0 session. </ins> The client session header is a sequence of 25 octets (in hex notation)
Code change:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Related discussion:
text: to process further frames.  Note that this does not address the concerns raised in TALKING. <del> The server session header is a SETTINGS.  The server sends the server session header (i.e., a SETTINGS frame) as the first frame in a new session. </del> <ins> The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. </ins> <del> The client sends requests immediately after sending the session header, without waiting to receive a server session header.  This ensures that confirming session headers does not add latency. </del> <ins> In order to avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. However, it is important to note that the server session header SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. </ins> <del> Both clients and servers MUST close the connection if it does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </del> <ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </ins> 3.3. <del> Once the connection is established, clients and servers exchange HTTP/2.0 frames.  Frames are the basic unit of communication. </del> <ins> Once the HTTP/2.0 session is established, clients and servers can begin exchanging frames. </ins> 3.3.1.
Code change:
Moves considerations of defining an ALPN token for a non-TLS-based protocol to 3.1. Changes "token" to "protocol identifier" in 3.3.

Related discussion:
text: A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. <del> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server. </del> <ins> HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS. </ins> Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.
Code change:
LGTM
Merged by RFC editor.
This wasn't obvious, but all descriptions of padding reference DATA: However, this is subtly wrong, as NAME notes. The actual text should be:

Related discussion:
text: HeaderBlock. The HEADERS frame can include padding.  Padding fields and flags are <del> identical to those defined for DATA. </del> <ins> identical to those defined for DATA.  Padding that exceeds the size remaining for the header block fragment MUST be treated as a . </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate
Code change:
This was confusing a few people who weren't clear if the prohibition on frame sending for CONTINUATION trumped this or not. This isn't a perfect fix, but it should be enough.
LGTM
Merged by RFC editor.

Related discussion:
text: 6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for any stream, including idle or closed streams. </del> <ins> be sent in any stream state, including idle or closed streams. </ins> The payload of a PRIORITY frame contains the following fields:
Code change:
This is a minimal proposal for solving .
LGTM
Lgtm as well. On Mar 17, 2015 9:47 AM, "Martin Thomson" EMAIL wrote:

Related discussion:
text: followed by the new maximum size, represented as an integer with a 5-bit prefix (see integer.representation). <del> The new maximum size MUST be lower than or equal to the last value of the maximum size of the dynamic table.  A value that exceeds this </del> <ins> The new maximum size MUST be lower than or equal to the limit determined by the protocol using HPACK.  A value that exceeds this </ins> limit MUST be treated as a decoding error.  In HTTP/2, this limit is the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see HTTP2) received from the decoder and acknowledged by the encoder (see
Code change:
LGTM
Merged by RFC editor.
Minor bug that needs to be tracked... I assume the text in section 6.2 needs to be modified to add "idle"?

Related discussion:
text: The HEADERS frame (type=0x1) is used to StreamStates, and additionally carries a header block fragment.  HEADERS frames can be <del> sent on a stream in the "open" or "half closed (remote)" states. </del> <ins> sent on a stream in the "idle", "reserved (local)", "open" or "half closed (remote)" states. </ins> The HEADERS frame payload has the following fields:
Code change:
This makes it clearer that they can't be sent otherwise.
LGTM
Merged by RFC editor.
has the following clarification added in draft 17: Should this be instead of ? If not I think we have an inconsistency with which has the following for the section:
NAME - Ping.
This is merely a problem with perspective. As in, there is none. I can provide that thusly: Does that work?
This is an improvement. I'm not sure if we can avoid it but it is a bit confusing with respect to :
I don't think that's a problem. The (remote) peer isn't sending, but the (local) peer can.
Agreed. Ship it :) Thanks!

Related discussion:
text: The PUSH_PROMISE frame defines the following flags: <del> PUSH_PROMISE frames MUST be associated with a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </del> <ins> PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </ins> associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type
Code change:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Related discussion:
text: The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. <del> In order to avoid unnecessary latency, clients are permitted to send </del> <ins> To avoid unnecessary latency, clients are permitted to send </ins> additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. <del> However, it is important to note that the server session header </del> <ins> It is important to note, however, that the server session header </ins> SETTINGS frame might include parameters that necessarily alter how a <del> client is expected to communicate with the server. </del> <ins> client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. </ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted
Code change:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Related discussion:
text: 3.3.1. <del> HTTP/2.0 frames share a common format, consisting of 8 byte of header with between 0 and 65535 bytes of data. </del> <ins> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </ins> The fields of the frame header are defined as: <del> The 16-bit length of the frame data in bytes.  The length of the frame header is not included. </del> <ins> The length of the frame data expressed as an unsigned, 16-bit integer.  The 8 bytes of the frame header are not included. </ins> The 8-bit type of the frame.  The frame type determines how the remainder of the frame header and data are interpreted.
Code change:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Related discussion:
text: FINAL flag is sent.  The active sender on the stream MUST be prepared to receive frames after closing the stream. <del> Either the peer can send a RST_STREAM control frame at any time to </del> <ins> Either peer can send a RST_STREAM control frame at any time to </ins> terminate an active stream.  RST_STREAM contains an error code to indicate the reason for termination.  A RST_STREAM indicates that the sender will transmit no further data on the stream and that
Code change:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Related discussion:
text: It is possible that the GOAWAY will not be reliably received by the receiving endpoint.  In the event of a session error, GOAWAY only provides a best-effort attempt to communicate with the peer about why <del> the session is going down. </del> <ins> the session is being terminated. </ins> An endpoint can end a session at any time.  In particular, an endpoint MAY choose to treat a stream error as a session error if the
Code change:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Related discussion:
text: 3.3. <del> A client that makes a request to an "https" URI uses TLS12 with the </del> <ins> A client that makes a request to an "https" URI uses TLS13 with the </ins> TLS-ALPN. HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c"