Clarifying upgrade options (#1).

draft-ietf-httpbis-http2.xml

@@ -314,29 +314,35 @@
  Once the server returns the 101 response, both the client and the server send a <xref
  target="SessionHeader">session header</xref>.
  </t>
-
- <t>
- A client can learn that a particular server supports HTTP/2.0 by other means. A client
- MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0.
- [[Issue #29: This is not definite. We may yet choose to perform negotiation for every
- connection. Reasons include intermediaries; phased upgrade of load-balanced server farms;
- etc...]] [[Issue #1: We need to enumerate the ways that clients can learn of HTTP/2.0
- support.]]
- </t>
  </section>
+
  <section anchor="discover-https" title="Starting HTTP/2.0 for &quot;https:&quot; URIs">
  <t>
  A client that makes a request to an "https:" URI without prior knowledge about support for
- HTTP/2.0 uses TLS with <xref target="TLSNPN">TLS-NPN</xref> extension. [[TBD, maybe NPN]]
+ HTTP/2.0 uses TLS with <xref target="TLSNPN">TLS-NPN</xref> extension. [[TBD, maybe ALPN]]
  </t>
 
  <t>
  Once TLS negotiation is complete, both the client and the server send a <xref
  target="SessionHeader">session header</xref>.
  </t>
+ </section>
 
+ <section anchor="known-http" title="Starting HTTP/2.0 with Prior Knowledge">
+ <t>
+ A client can learn that a particular server supports HTTP/2.0 by other means. A client
+ MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0. This
+ only affects the resolution of "http:" URIs, servers supporting HTTP/2.0 are required to
+ support <xref target="TLSNPN">protocol negotiation in TLS</xref>.
+ </t>
+ <t>
+ Prior support for HTTP/2.0 is not a strong signal that a given server will support
+ HTTP/2.0 for future sessions. It is possible for server configurations to change or for
+ configurations to differ between instances in clustered server. Different "transparent"
+ intermediaries - intermediaries that are not explicitly selected by either client or
+ server - are another source of variability.
+ </t>
  </section>
-
  </section>
 
  <section anchor="FramingLayer" title="HTTP/2.0 Framing Layer">
@@ -1345,8 +1351,8 @@
  <t>
  When a HTTP/2.0 connection is first established, new streams are created with an
  initial flow control window size of 65535 bytes. The session flow control window is
- also 65536 bytes. Both endpoints can adjust the initial window size for new streams
- by including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms
+ 65536 bytes. Both endpoints can adjust the initial window size for new streams by
+ including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame that forms
  part of the session header.
  </t>
  <t>