Code change:
3.2. <del> A client that makes a request for an "http" URI without prior knowledge about support for HTTP/2 on the next hop uses the HTTP Upgrade mechanism (HTTP).  The client does so by making an HTTP/1.1 request that includes an Upgrade header field with the "h2c" token. Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. For example: Requests that contain message content MUST be sent in their entirety before the client can send HTTP/2 frames.  This means that a large request can block the use of the connection until it is completely sent. If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to HTTP/2, at the cost of an additional round trip. A server that does not support HTTP/2 can respond to the request as though the Upgrade header field were absent: A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as described in discover-https. A server that supports HTTP/2 accepts the upgrade with a 101 (Switching Protocols) response.  After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames.  These frames MUST include a response to the request that initiated the upgrade. For example: The first HTTP/2 frame sent by the server MUST be a server connection preface (ConnectionHeader) consisting of a SETTINGS frame (SETTINGS). Upon receiving the 101 response, the client MUST send a ConnectionHeader, which includes a SETTINGS frame. The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers).  Stream 1 is implicitly "half-closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request. After commencing the HTTP/2 connection, stream 1 is used for the response. 3.2.1. A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one header field.  The header field is a connection-specific header field that includes settings that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST NOT send this header field. The content of the header field is the frame payload of a SETTINGS frame (SETTINGS), encoded as a base64url string (that is, the URL- and filename-safe Base64 encoding described in RFC4648, with any trailing '=' characters omitted).  The RFC5234 production for is defined in HTTP. Since the upgrade is only intended to apply to the immediate connection, a client sending the header field MUST also send as a connection option in the header field to prevent it from being forwarded (see HTTP). A server decodes and interprets these values as it would any other SETTINGS frame.  Explicit SettingsSync is not necessary, since a 101 response serves as implicit acknowledgement.  Providing these values in the upgrade request gives a client an opportunity to provide settings prior to receiving any frames from the server. 3.3. </del> A client that makes a request to an "https" URI uses TLS13 with the TLS-ALPN.

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.