Code change:
1. The Hypertext Transfer Protocol (HTTP) is a wildly successful <del> protocol.  However, the HTTP/1.1 message format (RFC7230) was designed to be implemented with the tools at hand in the 1990s, not modern Web application performance.  As such it has several </del> <ins> protocol.  However, the HTTP/1.1 message format (RFC7230) has several </ins> characteristics that have a negative overall effect on application performance today. <del> In particular, HTTP/1.0 only allows one request to be outstanding at a time on a given connection.  HTTP/1.1 pipelining only partially addressed request concurrency and suffers from head-of-line blocking. Therefore, clients that need to make many requests typically use multiple connections to a server in order to reduce latency. Furthermore, HTTP/1.1 header fields are often repetitive and verbose, which, in addition to generating more or larger network packets, can cause the small initial TCP congestion window to quickly fill.  This can result in excessive latency when multiple requests are made on a single new TCP connection. This specification addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields.  It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance. The resulting protocol is designed to be more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x.  This means less competition with other flows, and longer- lived connections, which in turn leads to better utilization of available network capacity. </del> <ins> In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.  Therefore, HTTP/1.1 clients that need to make many requests typically use multiple connections to a server in order to achieve concurrency and thereby reduce latency. Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary network traffic, as well as causing the initial TCP congestion window to quickly fill.  This can result in excessive latency when multiple requests are made on a new TCP connection. HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection.  Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields.  It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance. The resulting protocol is more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x.  This means less competition with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity. </ins> <del> Finally, this encapsulation also enables more efficient processing of messages through use of binary message framing. </del> <ins> Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing. </ins> 2.

Related discussion:
text: 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.