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

Commentary: Also addresses ( and integrates ) . 
 adds   , who got the ball rolling on the signaling draft -- we never acknowledged him for that in the combined draft , and I think the contributors section is the right place to do this . ( I also tried to order this by last name , for a possible guess what are the last names here . ) 
 2/1 Conference call with Signaling authors The current text : does not address the behavior of both endpoints . develops further : To avoid a deadlock , the connection initiator [ potential new terminology ] MUST NOT wait for the connection acceptor [ ugh ] to send its initial CSM message before sending the initiator ’s initial CSM message . Conversely , the acceptor  wait for the initiator to send its initial CSM message before sending the acceptor initial CSM message . 
 Closed in
In addition, some corporate networks only allow Internet access via a
HTTP proxy.  In this case, the best transport for CoAP might be the
RFC6455.  The WebSocket protocol provides two-way communication
between a client and a server after upgrading an RFC7230 connection
and may be available in an environment that blocks CoAP over UDP.
Another scenario for CoAP over WebSockets is a CoAP application
running inside a web browser without access to connectivity other
than HTTP and WebSockets.
In addition, some corporate networks only allow Internet access via a
HTTP proxy.  In this case, the best transport for CoAP might be the
RFC6455.  The WebSocket protocol provides two-way communication
between a WebSocket client and a WebSocket server after upgrading an
RFC7230 connection and may be available in an environment that blocks
CoAP over UDP.  Another scenario for CoAP over WebSockets is a CoAP
application running inside a web browser without access to
connectivity other than HTTP and WebSockets.
The peer that opens a reliable byte stream connection, i.e., the
TCP active opener, TLS client, or WebSocket client.
The peer that accepts the reliable byte stream connection opened
by the other peer, i.e., the TCP passive opener, TLS server, or
WebSocket server.
Once a connection is established, both the client and the server MUST
send a Capabilities and Settings message (CSM see csm) as its first
message on the connection.  This message establishes the initial
settings and capabilities for the endpoint such as maximum message
size or support for block-wise transfers.  The absence of options in
the CSM indicates that base values are assumed.
To avoid unnecessary latency, a client MAY send additional messages
without waiting to receive the server CSM; however, it is important
to note that the server CSM might advertise capabilities that impact
how a client is expected to communicate with the server.  For
example, the server CSM could advertise a Max-Message-Size option
(see max-message-size) that is smaller than the base value (1152).
Clients and servers MUST treat a missing or invalid CSM as a
connection error and abort the connection (see sec-abort).
Once a connection is established, both endpoints MUST send a
Capabilities and Settings message (CSM see csm) as their first
message on the connection.  This message establishes the initial
settings and capabilities for the endpoint such as maximum message
size or support for block-wise transfers.  The absence of options in
the CSM indicates that base values are assumed.
To avoid a deadlock, the Connection Initiator MUST NOT wait for the
Connection Acceptor to send its initial CSM message before sending
its own initial CSM message.  Conversely, the Connection Acceptor MAY
wait for the Connection Initiator to send its initial CSM message
before sending its own initial CSM message.
To avoid unnecessary latency, a Connection Initiator MAY send
additional messages without waiting to receive the Connection
Acceptor's CSM; however, it is important to note that the Connection
Acceptor's CSM might advertise capabilities that impact how the
initiator is expected to communicate with the acceptor.  For example,
the acceptor CSM could advertise a Max-Message-Size option (see max-
message-size) that is smaller than the base value (1152).
Endpoints MUST treat a missing or invalid CSM as a connection error
and abort the connection (see sec-abort).
If a client does not receive any response for some time after sending
a CoAP request (or, similarly, when a client observes a resource and
it does not receive any notification for some time), it can send a
CoAP Ping Signaling message (sec-ping) to test the connection and
verify that the server is responsive.
If a CoAP client does not receive any response for some time after
sending a CoAP request (or, similarly, when a client observes a
resource and it does not receive any notification for some time), it
can send a CoAP Ping Signaling message (sec-ping) to test the
connection and verify that the CoAP server is responsive.
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
to be updated or retrieved in the Proxy-Uri Option.
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 CoAP client specifies the
resource to be updated or retrieved in the Proxy-Uri Option.
As with CoAP over TCP, both the client and the server MUST send a
Capabilities and Settings message (CSM see csm) as its first message
on the WebSocket connection.
As with CoAP over TCP, both endpoints MUST send a Capabilities and
Settings message (CSM see csm) as their first message on the
WebSocket connection.
As with CoAP over TCP, the client can test the health of the CoAP
over WebSocket connection by sending a CoAP Ping Signaling message
(sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5
of RFC6455) SHOULD NOT be used to ensure that redundant maintenance
traffic is not transmitted.
As with CoAP over TCP, a CoAP client can test the health of the CoAP
over WebSocket connection by sending a CoAP Ping Signaling message
(sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5
of RFC6455) SHOULD NOT be used to ensure that redundant maintenance
traffic is not transmitted.
A client can use the critical Server-Name Option to indicate the
default value for the Uri-Host Options in the messages that it sends
to the server.  It has the same restrictions as the Uri-Host Option
(Section 5.10.1 of RFC7252).
For TLS, the base value for the Server-Name Option is given by the
SNI value.
For Websockets, the base value for the Server-Name Option is given by
the HTTP Host header field.
An endpoint can use the critical Default-Uri-Host Option to indicate
the default value for the Uri-Host Options in the messages that it
sends to the other endpoint.  Its value MUST be a valid value for the
Uri-Host Option (Section 5.10.1 of RFC7252).
For TLS, the base value for the Default-Uri-Host Option in the
direction from the Connection Initiator to the Connection Acceptor is
given by the SNI value.
For WebSockets, the base value for the Default-Uri-Host Option in the
direction from the Connection Initiator to the Connection Acceptor is
given by the HTTP Host header field.
The active value of the Default-Uri-Host Option is replaced each time
the option is sent with a modified value.  Its starting value is its
base value (if available).
The active value of the Max-Message-Size Option is replaced each time
the option is sent with a modified value.  Its starting value is its
base value.
The elective Bad-Server-Name Option indicates that the default
indicated by the CSM Server-Name Option is unlikely to be useful for
this server.
The elective Bad-Default-Uri-Host Option indicates that the default
indicated by the CSM Default-Uri-Host Option is unlikely to be useful
for this server.
The Alternative-Address Option is a repeatable option as defined in
Section 5.4.5 of RFC7252.
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.
If a TLS server does not support the Application-Layer Protocol
Negotiation Extension (ALPN) RFC7301 or wishes to accommodate TLS
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 TLS 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 TLS 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 TLS server either does not negotiate the ALPN
extension or returns a no_application_protocol alert, the TLS
client MUST close the connection.
For TCP port 5684, a TLS client MAY use the ALPN extension to
advertise the "coap" protocol identifier in the list of protocols
in its ClientHello.  If the TLS server selects and returns the
"coap" protocol identifier using the ALPN extension in its
ServerHello, then the connection succeeds.  If the TLS server
returns a no_application_protocol alert, then the TLS client MUST
close the connection.  If the TLS server does not negotiate the
ALPN extension, then coaps+tcp is implicitly selected.
For TCP port 5684, if the TLS client does not use the ALPN
extension to negotiate the protocol, then coaps+tcp is implicitly
selected.
SNI vs. Server-Name: Any security negotiated in the TLS handshake
is for the SNI name exchanged in the TLS handshake and checked
against the certificate provided by the server.  The Server-Name
Option cannot be used to extend these security properties to the
additional server name.
SNI vs. Default-Uri-Host: Any security negotiated in the TLS
handshake is for the SNI name exchanged in the TLS handshake and
checked against the certificate provided by the server.  The
Default-Uri-Host Option cannot be used to extend these security
properties to the additional server name.
Whether the option is critical or elective, as determined by the
Option Number.
Whether the option is repeatable.
The format and length of the option's value.
The base value for the option, if any.