Change:
9.5. <del> This document registers two new URI schemes, namely "coap+tcp" and "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over TCP, respectively.  The "coap+tcp" and "coaps+tcp" URI schemes can thus be compared to the "http" and "https" URI schemes. The syntax of the "coap" and "coaps" URI schemes is specified in Section 6 of RFC7252 and the present document re-uses their semantics for "coap+tcp" and "coaps+tcp", respectively, with the exception that TCP, or TLS over TCP is used as a transport protocol. IANA is requested to add these new URI schemes to the registry established with RFC7595. </del> <ins> URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [1]. </ins> 9.5.1. <del> This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+ws".  The registration request complies with RFC7595. </del> <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coap+tcp".  This registration request complies with RFC7595. </ins> <del> coap+ws </del> <ins> coap+tcp </ins> Permanent <del> Defined in Section N of [RFCthis] </del> <ins> The scheme is used by CoAP endpoints to access CoAP resources using TCP. </ins> <del> The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket protocol. </del> <ins> IETF chair <chair@ietf.org> </ins> <del> The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. </del> <ins> IESG <iesg@ietf.org> </ins> <del> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. </del> <ins> coap-tcp-scheme in [RFCthis] 9.5.2. </ins> <del> None. </del> <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coaps+tcp".  This registration request complies with RFC7595. </ins> <del> See Section N of [RFCthis] </del> <ins> coaps+tcp Permanent The scheme is used by CoAP endpoints to access CoAP resources using TLS. </ins> IETF chair <chair@ietf.org>

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: