Change:
6. <del> CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. </del> <ins> CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes. This document introduces four additional URI schemes for identifying CoAP resources and providing a means of locating the resource: </ins> <del> 6.1. </del> <ins> the "coap+tcp" URI scheme for CoAP over TCP the "coaps+tcp" URI scheme for CoAP over TCP secured by TLS the "coap+ws" URI scheme for CoAP over WebSockets the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS </ins> <del> CoAP over TCP uses the "coap+tcp" URI scheme.  CoAP over TLS uses the "coaps+tcp" scheme.  The rules from Section 6 of RFC7252 apply to both of these URI schemes. </del> <ins> Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers. The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty", and "query" are adopted from RFC3986. </ins> Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes. <del> Resources made available via one of the "coap+tcp" or "coaps+tcp" schemes have no shared identity with the other scheme or with the "coap" or "coaps" scheme, even if their resource identifiers indicate the same authority (the same host listening to the same port).  The schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers. </del> <ins> 6.1. </ins> <del> 6.1.1. </del> <ins> The "coap+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP. </ins> <del> The semantics defined in Section 6.1 of RFC7252 apply to this URI scheme, with the following changes: </del> <ins> The syntax defined in Section 6.1 of RFC7252 applies to this URI scheme with the following changes: </ins> The port subcomponent indicates the TCP port at which the CoAP server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.) <del> 6.1.2. </del> <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. </ins> <del> The semantics defined in Section 6.2 of RFC7252 apply to this URI </del> <ins> None. See Section 11.1 of RFC7252. 6.2. The "coaps+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP secured with TLS. The syntax defined in Section 6.2 of RFC7252 applies to this URI </ins> scheme, with the following changes: The port subcomponent indicates the TCP port at which the TLS

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: