Change:
given, then the default port 443 is assumed (this is different from the default port for "coaps", i.e., CoAP over DTLS over UDP). <del> If a server does not support the Application-Layer Protocol Negotiation Extension (ALPN) RFC7301 or wishes to accommodate </del> <ins> If a TCP server does not support the Application-Layer Protocol Negotiation Extension (ALPN) RFC7301 or wishes to accommodate TCP </ins> clients that do not support ALPN, it MAY offer a coaps+tcp endpoint on TCP port 5684.  This endpoint MAY also be ALPN <del> enabled.  A server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled. </del> <ins> enabled.  A TCP server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled. </ins> <del> For TCP ports other than port 5684, the client MUST use the ALPN extension to advertise the "coap" protocol identifier (see alpnpid) in the list of protocols in its ClientHello.  If the </del> <ins> For TCP ports other than port 5684, the TCP client MUST use the ALPN extension to advertise the "coap" protocol identifier (see alpnpid) in the list of protocols in its ClientHello.  If the TCP </ins> server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection <del> succeeds.  If the server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the client MUST close the connection. </del> <ins> succeeds.  If the TCP server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the TCP client MUST close the connection. </ins> <del> For TCP port 5684, a client MAY use the ALPN extension to </del> <ins> For TCP port 5684, a TCP client MAY use the ALPN extension to </ins> advertise the "coap" protocol identifier in the list of protocols <del> in its ClientHello.  If the server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds.  If the server returns a no_application_protocol alert, then the client MUST close the connection.  If the server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected. </del> <ins> in its ClientHello.  If the TCP server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds.  If the TCP server returns a no_application_protocol alert, then the TCP client MUST close the connection.  If the TCP server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected. </ins> <del> For TCP port 5684, if the client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected. </del> <ins> For TCP port 5684, if the TCP client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected. </ins> <del> 6.2. </del> <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. </ins> <del> For the first configuration discussed in websockets-overview, this document defines two new URIs schemes that can be used for identifying CoAP resources and providing a means of locating these resources: "coap+ws" and "coap+wss". </del> <ins> See Section 11.1 of RFC7252. </ins> <del> Similar to the "coap" and "coaps" schemes, the "coap+ws" and "coap+wss" schemes organize resources hierarchically under a CoAP origin server.  The key difference is that the server is potentially reachable on a WebSocket endpoint instead of a UDP endpoint. </del> <ins> 6.3. </ins> <del> The WebSocket endpoint is identified by a "ws" or "wss" URI that is composed of the authority part of the "coap+ws" or "coap+wss" URI, respectively, and the well-known path "/.well-known/coap" RFC5785. The path and query parts of a "coap+ws" or "coap+wss" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </del> <ins> The "coap+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets. </ins> <del> The syntax of the "coap+ws" and "coap+wss" URI schemes is specified below in Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty" and "query" are the same as in RFC3986. </del> <ins> The port component is OPTIONAL.  The default is port 80. </ins> <del> The port component is OPTIONAL; the default for "coap+ws" is port 80, while the default for "coap+wss" is port 443. </del> <ins> The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path "/.well-known/coap" RFC5785.  The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </ins> <del> Fragment identifiers are not part of the request URI and thus MUST NOT be transmitted in a WebSocket handshake or in the URI options of a CoAP request. </del> <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. See Section 11.1 of RFC7252. 6.4. </ins> <del> 6.2.1. </del> <ins> The "coaps+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS. </ins> <del> The steps for decomposing a "coap+ws" or "coap+wss" URI into CoAP options are the same as specified in Section 6.4 of RFC7252 with the following changes: </del> <ins> The port component is OPTIONAL.  The default is port 443. The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path "/.well-known/coap" RFC5785.  The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. </ins> <del> The <scheme> component MUST be "coap+ws" or "coap+wss" when converted to ASCII lowercase. </del> <ins> See Section 11.1 of RFC7252. </ins> <del> A Uri-Host Option MUST only be included in a request when the <host> component does not equal the uri-host component in the Host header field in the WebSocket handshake. </del> <ins> 6.5. </ins> <del> A Uri-Port Option MUST only be included in a request if |port| does not equal the port component in the Host header field in the WebSocket handshake. </del> <ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: </ins> <del> The steps to construct a URI from a request's options are changed accordingly. </del> <ins> If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws" then fail this algorithm. If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. 6.6. The steps are the same as specified in Section 6.5 of RFC7252 with the following changes: For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://".  Otherwise, let |url| be the string "coap+tcp://".  For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://".  Otherwise, let |url| be the string "coap+ws://". If the request includes a Uri-Port Option, let |port| be that option's value.  Otherwise, let |port| be the request's destination TCP port. </ins> 7.

Discussion:
URL Ensure that all "Section N" references are updated.
URL Cl.8.5: I think it would be easier for IANA if the coaps+tcp and coap+tcp URI schemes were described like the websockets ones in 8.5.1 and 8.5.2. This is another case with a heavy dependency on RFC7252 references.
URL We need to fill in the template.
URL s/are potentially accessible/are intended to be accessible/ [Editor] Same language is used for coap+wss. [Editor] Ironically, "potentially accessible" was copied from CoAP Classic - RFC7252. ~
URL Cl.6.2: This indicates ABNF is used for the definitions. However clause 6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 6.1.1 and 6.1.2 should be harmonised. This could be more consistent. Currently, coap+tcp and coaps+tcp rely on references to coap and coaps in RFC7252: The semantics defined in [RFC7252], Section 6.1, apply to this URI scheme, with the following changes and require that the reader is also familiar with URL The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
Additional feedback - URL CoAP URIs In this section, the terms "client" and "server" are used WRT the TCP connection, not WRT CoAP, and that may be very confusing. Maybe use different terms here (initiator/responder)? [Note from editor] - The terms are used in the coaps+tcp section on ALPN. Since there are already references to ClientHello and ServerHello perhaps it could be clarified with "TCP client" and "TCP server"? 6.1.

CoAP over TCP and TLS URIs Not sure this belongs here, but it also should apply to 6.2, so maybe move it up to 6. Ditto. s/potentially reachable/intended to be reached/ The following paragraph applies to 6.1.1, 6.1.2, and this subsection. (Move up to 6.) (They can't be in a CoAP request; not sure what the MUST NOT means. But again, this also applies to the TCP/TLS case.) 6.2.1. Decomposing and Composing URIs Wrong use of MUST. (MUST it be included or is this a MUST NOT if equal?) Ditto.
The outline for the URI scheme definitions needs to follow the guidance in URL which now requires: