more clarification around HTTP/1.x vs HTTP/2

draft-dkg-dprive-demux-dns-http.md

 ---
-title: Demultiplexing Streamed DNS from HTTP
+title: Demultiplexing Streamed DNS from HTTP/1.x
 docname: draft-dkg-dprive-demux-dns-http-02
 date: 2017-05-03
 category: info
@@ -77,13 +77,13 @@ should place no constraints on it or any higher version of HTTP.
 Introduction
 ============
 
-DNS and HTTP/1.1 are both client-speaks-first protocols capable of
+DNS and HTTP/1.x are both client-speaks-first protocols capable of
 running over stream-based transport like TCP, or as the payload of a
 typical TLS {{RFC5246}} session.
 
 There are some contexts where it is useful for a server to be able to
 decide what protocol is used by an incoming TCP stream, to choose
-dynamically between DNS and HTTP/1.1 on the basis of the stream itself
+dynamically between DNS and HTTP/1.x on the basis of the stream itself
 (rather than a port designation or other explicit demultiplexing).
 
 For example, a TLS terminator listening on port 443 and receiving
@@ -135,7 +135,7 @@ initial few octets sent by the client.
 
 While it's tempting to consider distinguishing at multiple points in
 the stream, the complexities of determining the specific end of an
-HTTP/1.1 request body and handling HTTP/1.x error cases make this more
+HTTP/1.x request body and handling HTTP/1.x error cases make this more
 difficult to implement on the side of a DNS client configured to talk
 to such a server.  Interleaving the responses themselves on a stream
 with multiple data elements is also challenging.  So do not use this
@@ -150,11 +150,13 @@ HTTP/2 is not always client-speaks-first
 
 While this demultiplexing technique functions for HTTP/1.0 and
 HTTP/1.1, it does not work for HTTP/2 {{RFC7540}} because HTTP/2 is
-not guaranteed to be a client-speaks-first protocol.  In the event
-that HTTP/2 is to be transported over TLS, the ALPN token negotiated
-in the TLS session is "h2", which allows the server to know as soon as
-the handshake is complete that it can start pushing data to the
-client.
+not guaranteed to be a client-speaks-first protocol.  In particular,
+many HTTP/2 servers prefer to send a SETTINGS frame immediately
+without waiting for data from the client, if they already know they're
+speaking HTTP/2.  In the event that HTTP/2 is to be transported over
+TLS, the ALPN token negotiated in the TLS handshake is "h2", which
+allows the server to know as soon as the handshake is complete that it
+can start pushing data to the client.
 
 A standard DNS-over-TLS client connecting to a server that might be
 multiplexing DNS with HTTP on the same listener MUST NOT indicate an