Re: [quicwg/base-drafts] Pull some H2 content into the introduction (#2683)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Generally pretty good.

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads

It isn't just the whitespace, but the use of whitespace for delineation makes some aspects of parsing and processing difficult.  You should be careful not to talk about shortcomings that this version doesn't address.

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads
+to parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection can transfer only a single HTTP request or response at a
+time in each direction, multiple parallel TCP connections are used, reducing the

"are used" or "are often used"

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads
+to parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection can transfer only a single HTTP request or response at a
+time in each direction, multiple parallel TCP connections are used, reducing the
+ability of the congestion controller to accurately manage traffic between
+endpoints.

Only because people haven't worked out how to run the same congestion controller for multiple connections.  I mean, there is no reason you can't do that... in theory.

>  
-## Notational Conventions
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint can be discovered using HTTP Alternative Services; this
+process is described in greater detail in {{discovery}}.  Once a client knows
+that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection.
+QUIC provides protocol negotiation, stream-based multiplexing, and flow control.

I'd invert this paragraph.  The key points are in the second sentence.  The alternative services thing is really secondary here.

>  
+endpoint:
+: Either the client or server of the connection.

Love the circular definition here.

>  
 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important
 differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
 
 HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not
-a hard requirement.  HTTP/3 departs from HTTP/2 primarily where necessary to
-accommodate the differences in behavior between QUIC and TCP (lack of ordering,
-support for streams).  We intend to avoid gratuitous changes which make it
-difficult or impossible to build extensions with the same semantics applicable
-to both protocols at once.
+a hard requirement.  HTTP/3 departs from HTTP/2 where QUIC's behavior
+differences from TCP (lack of ordering, support for streams) are either

```suggestion
where QUIC differs from TCP, either to take advantage of QUIC features (like streams) or to accommodate important shortcomings (such as a lack of total ordering).
```

>  
 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important
 differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
 
 HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not
-a hard requirement.  HTTP/3 departs from HTTP/2 primarily where necessary to
-accommodate the differences in behavior between QUIC and TCP (lack of ordering,
-support for streams).  We intend to avoid gratuitous changes which make it
-difficult or impossible to build extensions with the same semantics applicable
-to both protocols at once.
+a hard requirement.  HTTP/3 departs from HTTP/2 where QUIC's behavior
+differences from TCP (lack of ordering, support for streams) are either
+beneficial or need to be accommodated.  HTTP/3 attempts to avoid gratuitous
+changes which make it difficult or impossible to build extensions with the same
+semantics applicable to both protocols at once.

I think that we can lose this sentence now.  It might be time to face up to reality:

> These differences make HTTP/3 similar to HTTP/2 in key aspects, such as the relationship of requests and responses to streams.  However, the details of the HTTP/3 design are substantially different than HTTP/2.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683#pullrequestreview-236990732