jiebi/CodeConvo huggingface dataset:
Code change:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Related discussion:
text: use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. <del> Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. </del> <ins> The effect of these restrictions is that TLS 1.2 implementations could have non-intersecting sets of available cipher suites, since these prevent the use of the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with P256 FIPS186. Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.  This enables a fallback to protocols without these constraints without the additional latency imposed by using a separate connection for fallback. </ins> An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these
Code change:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Related discussion:
text: A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established <del> in TLSALPN. </del> <ins> in TLS-ALPN. </ins> This document establishes a registry for frame types, settings, and error codes.  These new registries are entered into a new "Hypertext
Code change:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Related discussion:
text: This document creates two registrations for the identification of HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol <del> IDs" registry established in TLSALPN. </del> <ins> IDs" registry established in TLS-ALPN. </ins> The "h2" string identifies HTTP/2 when used over TLS:
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). <del> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a </del> <ins> Header lists are collections of zero or more header fields.  When transmitted over a connection, a header list is serialized into a </ins> header block using COMPRESSION.  The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames. <del> HTTP Header Compression does not preserve the relative ordering of header fields.  Header fields with multiple values are encoded into a single header field using a special delimiter (see HeaderOrdering), this preserves the relative order of values for that header field. </del> The COOKIE is treated specially by the HTTP mapping (see CompressCookie). A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header <del> set. </del> <ins> list. </ins> A complete header block consists of either:
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: Field Registry maintained at <https://www.iana.org/assignments/ message-headers>. <ins> 8.1.2.1. </ins> While HTTP/1.x used the message start-line (see RFC7230) to convey the target URI and method of the request, and the status code for the response, HTTP/2 uses special pseudo-header fields beginning with ':'
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. <ins> All pseudo-header fields MUST appear in the header block before regular header fields.  Any request or response that contains any pseudo-header field that appears in a header block after a regular header field MUST treated as malformed. 8.1.2.2. </ins> HTTP/2 does not use the Connection header field to indicate "hop-by- hop" header fields; in this protocol, connection-specific metadata is conveyed by other means.  As such, a HTTP/2 message containing
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: The handshake methods described in starting are believed sufficient to negotiate the use of alternative protocols. <del> 8.1.2.1. </del> <ins> 8.1.2.3. </ins> HTTP/2 defines a number of pseudo header fields starting with a colon ':' character that carry information about the request target:
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: HTTP/2 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. <del> 8.1.2.2. </del> <ins> 8.1.2.4. </ins> A single ":status" header field is defined that carries the HTTP status code field (see RFC7231).  This header field MUST be included
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. <del> 8.1.2.3. COMPRESSION does not preserve the order of header fields, because the relative order of header fields with different names is not important.  However, the same header field can be repeated to form a list (see RFC7230), where the relative order of header field values is significant.  This repetition can occur either as a single header field with a comma-separated list of values, or as several header fields with a single value, or any combination thereof.  Therefore, in the latter case, ordering needs to be preserved before compression takes place. To preserve the order of multiple occurrences of a header field with the same name, its ordered values are concatenated into a single value using a zero-valued octet (0x0) to delimit them. After decompression, header fields that have values containing zero octets (0x0) MUST be split into multiple header fields before being processed. For example, the following HTTP/1.x header block: contains three Cache-Control directives; two directives in the first Cache-Control header field, and the third directive in the second Cache-Control field.  Before compression, they would need to be converted to a form similar to this (with 0x0 represented as '\0'): Note here that the ordering between Content-Type and Cache-Control is not preserved, but the relative ordering of the Cache-Control directives - as well as the fact that the first two were comma- separated, while the last was on a different line - is. Header fields containing multiple values MUST be concatenated into a single value unless the ordering of that header field is known to be not significant. The special case of "set-cookie" - which does not form a comma- separated list, but can have multiple values - does not depend on ordering.  The "set-cookie" header field MAY be encoded as multiple header field values, or as a single concatenated value. 8.1.2.4. </del> <ins> 8.1.2.5. </ins> The COOKIE can carry a significant amount of redundant data.
Code change:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Related discussion:
text: before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application. <del> The Cookie header field MAY be split using a zero octet (0x0), as defined in HeaderOrdering.  When decoding, zero octets MUST be replaced with the cookie delimiter ("; "). 8.1.2.5. </del> <ins> 8.1.2.6. </ins> A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the
Code change:
Looks like I caught some trailing whitespace at the same time.
The trailing whitespace came from an automatically generated part of the spec and will reappear if I ever re-generate the examples. In addition, it really should be here ;-).

Related discussion:
text: at the index corresponding to the number of entries in the header table. <del> The header table is initially empty. </del> <ins> The header table is initially empty.  Entries are added as each header block is decompressed. </ins> The header table can contain duplicate entries.  Therefore, duplicate entries MUST NOT be treated as an error by a decoder.
Code change:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Related discussion:
text: Abstract <del> This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </del> <ins> This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </ins> efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection.  It also introduces
Code change:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Related discussion:
text: are used in support of other HTTP/2 features. Multiplexing of requests is achieved by having each HTTP request- <del> response exchanged assigned to a single StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request does not prevent progress on other requests. </del> <ins> response exchange associated with its own StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. </ins> Flow control and prioritization ensure that it is possible to <del> properly use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </del> <ins> efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </ins> StreamPriority ensures that limited resources can be directed to the <del> most important requests first. </del> <ins> most important streams first. </ins> HTTP/2 adds a new interaction mode, whereby a server can PushResources.  Server push allows a server to speculatively send a
Code change:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Related discussion:
text: using frames and streams. While some of the frame and stream layer concepts are isolated from <del> HTTP, the intent is not to define a completely generic framing layer. The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </del> <ins> HTTP, this specification does not define a completely generic framing layer.  The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </ins> 2.2.
Code change:
I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.

Related discussion:
text: 8.2. HTTP/2 allows a server to pre-emptively send (or "push") responses <del> (along with corresponding requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del> <ins> (along with corresponding "promised" requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </ins> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The setting can be set to 0 to indicate that server push is disabled. <ins> Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type . Pushed responses that are cacheable (see RFC7234) SHOULD be stored by the client, if it implements a HTTP cache.  Such responses MAY be 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. Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.  They MAY be made available to the application separately. </ins> Because server push is effectively hop-by-hop, an intermediary could receive pushes from the server and choose not to forward them on to the client.  In other words, how to make use of the pushed
Code change:
I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.

Related discussion:
text: . <del> A server can only push responses that are cacheable (see RFC7234); promised requests MUST be safe (see RFC7231) and MUST NOT include a request body. </del> 8.2.1. Server push is semantically equivalent to a server responding to a
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: frame.  SettingsSync is not necessary, since a 101 response serves as implicit acknowledgment.  Providing these values in the Upgrade <del> request ensures that the protocol does not require default values for the above SETTINGS parameters, and gives a client an opportunity to provide other parameters prior to receiving any frames from the server. </del> <ins> request gives a client an opportunity to provide parameters prior to receiving any frames from the server. </ins> 3.3. <del> A client that makes a request to an "https" URI without prior knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </del> <ins> A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.
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: frame (WINDOW_UPDATE).  This document does not stipulate how a receiver decides when to send this frame or the value that it <del> sends.  Nor does it specify how a sender chooses to send packets. </del> <ins> sends, nor does it specify how a sender chooses to send packets. </ins> Implementations are able to select any algorithm that suits their needs.