Change:
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> <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 <del> to be updated or retrieved in the Proxy-URI Option. </del> <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

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: