Draft: draft-ietf-core-coap-tcp-tls

Commentary: Ensure that all " Section N " references are updated . 
 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  references . 
 We need to fill in the template . 
 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 . ~ 
 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  should be harmonised . This could be more consistent . Currently , coap+tcp and coaps+tcp rely on references to coap and coaps in  : 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 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 - 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 ,  , and this subsection . ( Move up to 6 . ) ( They ca n'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 which now requires :
The challenge with this configuration is how to identify a resource
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
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.
The challenge with this configuration is how to identify a resource
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
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.
CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for
identifying CoAP resources and providing a means of locating the
resource.
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.
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.
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.
The "coap+tcp" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over TCP.
The "coaps+tcp" URI scheme identifies CoAP resources that are
intended to be accessible using CoAP over TCP secured with TLS.
If a server does not support the Application-Layer Protocol
Negotiation Extension (ALPN) RFC7301 or wishes to accommodate
clients that do not support ALPN, it MAY offer a coaps+tcp
endpoint on TCP port 5684.  This endpoint MAY also be ALPN
enabled.  A server MAY offer coaps+tcp endpoints on ports other
than TCP port 5684, which MUST be ALPN enabled.
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
server selects and returns the "coap" protocol identifier using
the ALPN extension in its ServerHello, then the connection
succeeds.  If the server either does not negotiate the ALPN
extension or returns a no_application_protocol alert, the client
MUST close the connection.
For TCP port 5684, a client MAY use the ALPN extension to
advertise the "coap" protocol identifier in the list of protocols
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.
For TCP port 5684, if the client does not use the ALPN extension
to negotiate the protocol, then coaps+tcp is implicitly selected.
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".
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.
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.
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.
The port component is OPTIONAL; the default for "coap+ws" is port 80,
while the default for "coap+wss" is port 443.
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.
The <scheme> component MUST be "coap+ws" or "coap+wss" when
converted to ASCII lowercase.
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.
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.
The steps to construct a URI from a request's options are changed
accordingly.
If a TCP server does not support the Application-Layer Protocol
Negotiation Extension (ALPN) RFC7301 or wishes to accommodate TCP
clients that do not support ALPN, it MAY offer a coaps+tcp
endpoint on TCP port 5684.  This endpoint MAY also be ALPN
enabled.  A TCP server MAY offer coaps+tcp endpoints on ports
other than TCP port 5684, which MUST be ALPN enabled.
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
server selects and returns the "coap" protocol identifier using
the ALPN extension in its ServerHello, then the connection
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.
For TCP port 5684, a TCP client MAY use the ALPN extension to
advertise the "coap" protocol identifier in the list of protocols
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.
For TCP port 5684, if the TCP client does not use the ALPN
extension to negotiate the protocol, then coaps+tcp is implicitly
selected.
The "coap+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets.
The port component is OPTIONAL.  The default is port 80.
The "coaps+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets secured by TLS.
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.
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|.
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.
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.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+ws".  The registration request complies
with RFC7595.
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.
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].
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coap+tcp".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using TCP.
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coaps+tcp".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using TLS.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+wss".  The registration request
complies with RFC7595.
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).
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coap+ws".  This registration request complies with RFC7595.
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coaps+ws".  This registration request complies with RFC7595.