Original text:
connection after sending the closure alert, thus generating an incomplete close on the client side. <del> 9.9. The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocol names in the Upgrade header field of a request to invite the server to switch to one or more of the named protocols, in order of descending preference, before sending the final response.  A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.  Upgrade cannot be used to insist on a protocol change. Although protocol names are registered with a preferred case, recipients SHOULD use case-insensitive comparison when matching each protocol-name to supported protocols. A server that sends a response MUST send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol layers are being switched, the sender MUST list the protocols in layer-ascending order.  A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field.  A server MAY choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such as the nature of the request or the current load on the server. A server that sends a response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending preference. A server MAY send an Upgrade header field in any other response to advertise that it implements support for upgrading to the listed protocols, in order of descending preference, when appropriate for a future request. The following is a hypothetical example sent by a client: The capabilities and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s) chosen.  However, immediately after sending the response, the server is expected to continue responding to the original request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated). For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first responds with a message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of an additional round trip.  A server MUST NOT switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored by any protocol. The following is an example response to the above hypothetical request: When Upgrade is sent, the sender MUST also send a header field (field.connection) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries that might not implement the listed protocols.  A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request. A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message). If a server receives both an Upgrade and an header field with the "100-continue" expectation (field.expect), the server MUST send a response before sending a response. The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transport) protocol, nor to switch the existing communication to a different connection.  For those purposes, it is more appropriate to use a response (status.3xx). 9.9.1. This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of protocol.version and future updates to this specification.  Additional protocol names ought to be registered using the registration procedure defined in upgrade.token.registry. 9.9.2. The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the header field.  The registry is maintained at <https://www.iana.org/assignments/http-upgrade-tokens>. Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded. Registrations happen on a "First Come First Served" basis (see RFC8126) and are subject to the following rules: </del> 10. 10.1.

Reviewer comments:
These are just the cherry picked moves from that are moving sections to Semantics.
created issue for this
See

Revised text:
connection after sending the closure alert, thus generating an incomplete close on the client side.  10. 10.1.