Original text:
in the namespace of the CoAP server.  When the WebSocket protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket <del> endpoint.  This means it is necessary for the client to identify both the WebSocket endpoint (identified by a "ws" or "wss" URI) and the path and query of the CoAP resource within that endpoint from the same URI.  When the WebSocket protocol is used from a web page, the choices are more limited RFC6454, but the challenge persists. uris defines a new "coap+ws" URI scheme that identifies both a WebSocket endpoint and a resource within that endpoint as follows: </del>  Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint.  Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint.  The client specifies the resource <del> to be updated or retrieved in the Proxy-URI Option. </del>  A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket 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>  <del> 6.1. </del>  <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>  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>  <del> 6.1.1. </del>  <del> The semantics defined in Section 6.1 of RFC7252 apply to this URI scheme, with the following changes: </del>  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>  <del> The semantics defined in Section 6.2 of RFC7252 apply to this URI </del>  scheme, with the following changes: The port subcomponent indicates the TCP port at which the TLS 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>  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>  <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>  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>  <del> For TCP port 5684, a client MAY use the ALPN extension to </del>  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>  <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>  <del> 6.2. </del>  <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>  <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>  <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>  <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>  <del> The port component is OPTIONAL; the default for "coap+ws" is port 80, while the default for "coap+wss" is port 443. </del>  <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>  <del> 6.2.1. </del>  <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>  <del> The <scheme> component MUST be "coap+ws" or "coap+wss" when converted to ASCII lowercase. </del>  <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>  <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>  <del> The steps to construct a URI from a request's options are changed accordingly. </del>  7. 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>  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>  <del> coap+ws </del>  Permanent <del> Defined in Section N of [RFCthis] </del>  <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>  <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>  <del> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. </del>  <del> None. </del>  <del> See Section N of [RFCthis] </del>  IETF chair <chair@ietf.org> IESG <iesg@ietf.org> <del> [RFCthis] </del>  <del> 9.5.2. </del>  <del> This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+wss".  The registration request complies with RFC7595. </del>  <del> coap+wss </del>  Permanent <del> Defined in Section N of [RFCthis] </del>  <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 secured with Transport Layer Security (TLS). </del>  <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>  <del> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. </del>  <del> None. </del>  <del> See Section N of [RFCthis] </del>  IETF chair <chair@ietf.org> IESG <iesg@ietf.org> <del> [RFCthis] </del>  9.6. [RFCthis] 

Reviewer comments:
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:

Revised text:
in the namespace of the CoAP server.  When the WebSocket protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket  <ins> endpoint. coap-ws-scheme and coaps-ws-scheme define new URI schemes that enable the client to identify both a WebSocket endpoint and the path and query of the CoAP resource within that endpoint.  When the WebSocket protocol is used from a web page, the choices are more limited RFC6454, but the challenge persists. </ins> Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint.  Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint.  The client specifies the resource  <ins> to be updated or retrieved in the Proxy-Uri Option. </ins> A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket 6.  <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>  <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>  <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.  <ins> 6.1. </ins>  <ins> The "coap+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP. </ins>  <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.)  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. </ins>  <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 given, then the default port 443 is assumed (this is different from the default port for "coaps", i.e., CoAP over DTLS over UDP).  <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  <ins> enabled.  A TCP server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled. </ins>  <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  <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>  <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  <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>  <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>  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. </ins>  <ins> See Section 11.1 of RFC7252. </ins>  <ins> 6.3. </ins>  <ins> The "coap+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets. </ins>  <ins> The port component is OPTIONAL.  The default is port 80. </ins>  <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>  <ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. None. See Section 11.1 of RFC7252. 6.4. </ins>  <ins> The "coaps+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS. </ins>  <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>  <ins> See Section 11.1 of RFC7252. </ins>  <ins> 6.5. </ins>  <ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: </ins>  <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. 9.5.  <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.  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coap+tcp".  This registration request complies with RFC7595. </ins>  <ins> coap+tcp </ins> Permanent  <ins> The scheme is used by CoAP endpoints to access CoAP resources using TCP. </ins>  <ins> IETF chair <chair@ietf.org> </ins>  <ins> IESG <iesg@ietf.org> </ins>  <ins> coap-tcp-scheme in [RFCthis] 9.5.2. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coaps+tcp".  This registration request complies with RFC7595. </ins>  <ins> coaps+tcp Permanent The scheme is used by CoAP endpoints to access CoAP resources using TLS. </ins> IETF chair <chair@ietf.org> IESG <iesg@ietf.org>  <ins> coaps-tcp-scheme in [RFCthis] </ins>  <ins> 9.5.3. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coap+ws".  This registration request complies with RFC7595. </ins>  <ins> coap+ws </ins> Permanent  <ins> The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. </ins>  <ins> IETF chair <chair@ietf.org> </ins>  <ins> IESG <iesg@ietf.org> </ins>  <ins> coap-ws-scheme in [RFCthis] 9.5.4. </ins>  <ins> IANA is requested to register the Uniform Resource Identifier (URI) scheme "coaps+ws".  This registration request complies with RFC7595. coaps+ws </ins>  <ins> Permanent The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. </ins> IETF chair <chair@ietf.org> IESG <iesg@ietf.org>  <ins> coaps-ws-scheme in [RFCthis] </ins> 9.6. [RFCthis] <ins> 10.  References 10.1.  URIs [1] http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml </ins>