Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.  7.1. The "coap+tcp" URI scheme identifies CoAP resources that are intended

RFC 7252 says about : in Section 6.1 of RFC 7252; it is maybe an erratum that we didn’t do the same in Section 6.2. In any case, we need to do this for all the new URI schemes we define in the current spec, probably best by a blanket statement for all of them at the start of section 7.
RFC 7252 Section 6.2 specifies support for .well-known paths by saying All of the requirements listed above for the "coap" scheme are also requirements for the "coaps" scheme [...] At least that's the intention.
OK, it is not clear that extending is a "requirement", so to me this is at least a "hold for document update" style erratum for RFC 7252. But it is good that the right intention is in there, even if not unambiguously said so.

Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes. <ins> As with the "coap" and "coaps" schemes defined in RFC7252, all URI schemes defined in this section also support the path prefix "/.well- known/" defined by RFC5785 for "well-known locations" in the namespace of a host.  This enables discovery as per Section 7 of RFC7252. </ins> 7.1. The "coap+tcp" URI scheme identifies CoAP resources that are intended


Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets <del> transports.  It also formally updates RFC7641 for use with these </del>  transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. 1. The RFC7252 was designed for Internet of Things (IoT) deployments, <del> assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </del>  Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received of a byte-stream.  A Block1 or Block2 option that includes an SZX value of 7.

Updates for acronyms Minor style change to Abstract
Please spell out acronyms at first use. I will correct the BERT case and also review URL for other potential cases.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets  <ins> transports.  It also formally updates RFC 7641 for use with these </ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. 1. The RFC7252 was designed for Internet of Things (IoT) deployments,  <ins> assuming that UDP RFC0768 or Datagram Transport Layer Security (DTLS) RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </ins> Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received of a byte-stream. <ins> BERT extends RFC7959 to enable the use of larger messages over a reliable transport. </ins> A Block1 or Block2 option that includes an SZX value of 7.


TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies. <del> The "NoSec" mode is mandatory-to-implement.  The system simply sends </del>  the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port.  The system is secured only by keeping attackers from being able to send or receive packets from the

: Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review. I Carsten's position that this could become optional. History: Some context - during the security discussions in the WG, there was a recommendation to "mirror" the similar section in RFC7252. URL states: The NoSec and RawPublicKey modes are mandatory to implement for this specification. which is why NoSec is MTI.

TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies.  <ins> The "NoSec" mode is optional-to-implement.  The system simply sends </ins> the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port.  The system is secured only by keeping attackers from being able to send or receive packets from the


reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these <del> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </del>  1. [RFCthis]  11.  References 11.1.  URIs

Add to Updates Updated Abstract Added IANA section to update related references for Block1 and Block2
: 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. My sense is that we should treat this as an update to RFC7959 based on the original language: and the use of "extension" in coap-tcp-tls: This also requires an IANA addition, since the entries for Block1 and Block2 need to also reference coap-tcp-tls in addition to RFC7959.

reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these  <ins> transports, RFC 7959 to enable the use of larger messages over a reliable transport, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1. [RFCthis] <ins> 10.9. IANA is requested to add [RFCthis] to the references for the following entries registered by RFC7959 in the "CoAP Option Numbers" sub-registry defined by RFC7252: </ins> 11.  References 11.1.  URIs


by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server. <del> For simplicity, a Payload Marker (0xFF) is shown in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252). </del> 3. The request/response interaction model of CoAP over TCP is the same introduces a length field with variable size. fig-frame shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which <del> includes the length information of variable size, shown here as an 8-bit length. </del>  4-bit unsigned integer.  A value between 0 and 12 directly indicates the length of the message in bytes starting with the The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of RFC7252). <del> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </del>  For example: A CoAP message just containing a 2.03 code with the <del> token 7f and no options or payload would be encoded as shown in fig- frame2. </del>  The semantics of the other CoAP header fields are left unchanged. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined <del> in this document.  Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. </del>  The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be <del> in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del>  Release messages are indicated by the 7.04 code (Release). abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort <del> message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del>  Abort messages are indicated by the 7.05 code (Abort). Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such <del> messages by sending an Abort message and otherwise ignoring the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </del>  5.7.

Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)

by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server.  3. The request/response interaction model of CoAP over TCP is the same introduces a length field with variable size. fig-frame shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which  <ins> includes the length information of variable size. </ins> 4-bit unsigned integer.  A value between 0 and 12 directly indicates the length of the message in bytes starting with the The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of RFC7252).  <ins> For simplicity, a Payload Marker (0xFF) is shown in fig-frame; the Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252).  (If present, the Payload Marker is included in the message length, which counts from the start of the Options field to the end of the Payload field.) </ins> For example: A CoAP message just containing a 2.03 code with the  <ins> token 7f and no options or payload is encoded as shown in fig-frame2. </ins> The semantics of the other CoAP header fields are left unchanged. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined  <ins> in this document. </ins> The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be  <ins> in flight or responses outstanding when the sender decides to send a Release message.  The peer responding to the Release message SHOULD delay the closing of the connection until it has responded to all requests received by it before the Release message.  It also MAY wait for the responses to its own requests. </ins> Release messages are indicated by the 7.04 code (Release). abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort  <ins> message.  Messages may be in flight or responses outstanding when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort). Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such  <ins> messages by sending an Abort message and otherwise ignoring (not processing) the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </ins> 5.7.


fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size. <del> 4-bit unsigned integer.  A value between 0 and 12 directly </del>  indicates the length of the message in bytes starting with the first bit of the Options field.  Three values are reserved for special constructs: messages send a modified value. These are not default values for the option, as defined in <del> Section 5.4.4 in RFC7252.  A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. </del>  Capabilities and Settings messages are indicated by the 7.01 code (CSM).

(1) s/between 0 and 12/& inclusive/ (2) maybe revisit the language about default values vs. origin values for CSM options:

fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size.  <ins> 4-bit unsigned integer.  A value between 0 and 12 inclusive </ins> indicates the length of the message in bytes starting with the first bit of the Options field.  Three values are reserved for special constructs: messages send a modified value. These are not default values for the option, as defined in  <ins> Section 5.4.4 in RFC7252.  Default values apply on a per-message basis and thus reset when the value is not present in a given Capabilities and Settings message. </ins> Capabilities and Settings messages are indicated by the 7.01 code (CSM).


bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong <del> message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </del>  Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).

s/Unless there is an option with delaying semantics/Unless the PING carries an option with delaying semantics/

bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong  <ins> message with an identical token in response.  Unless the Ping carries an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </ins> Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).


3.3. <del> Once a connection is established, both endpoints MUST send a </del>  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 4.3. <del> As with CoAP over TCP, both endpoints MUST send a Capabilities and </del>  Settings message (CSM see csm) as their first message on the WebSocket connection. Each setting option indicates a setting that will be applied by the sender. <del> One CSM MUST be sent by both endpoints at the start of the connection.  Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </del>  Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined <del> in Section 12.2 of RFC7252. </del>  The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following

Partially addresses
It is analogous, because the structure of the subregistry is slightly different (additional column). We can add a sentence that the value of the additional column does not influence the choice of the policy. Good point. OK, “update” is not the right word them. Good point. It was smeared all over the document, and then we collected it in an appendix. I don’t think anyone would have a strong opposition against making it a mainline section. Should we?
In general, I prefer to separate out unrelated issues (editorial or not) to simplify tracking/closing: Regarding: There are at least three similar cases of "both endpoints" which would need to be corrected together.
NAME - Regarding Ben's comment (which you seem to concur with ...): 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." The text actually updates RFC7252 to address all cases. I don't see how it effectively removes UDP support since the text is additive. For example: This step from [RFC7252]: If does not equal the request’s destination UDP port, include a Uri-Port Option and let that option’s value be . is updated to: If does not equal the request’s destination UDP port or TCP port, include a Uri-Port Option and let that option’s value be .
NAME - I do not feel strongly about moving Appendix A - but I'm open to suggestions. It's hard to find the right place in the flow - perhaps before/after Section 6?
This issue is partially addressed by - which I'm merging now since I'm on leave for the next two weeks. The other potential editorial changes are pending responses from NAME

3.3.  <ins> Once a connection is established, each endpoint MUST send a </ins> 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 4.3.  <ins> As with CoAP over TCP, each endpoint MUST send a Capabilities and </ins> Settings message (CSM see csm) as their first message on the WebSocket connection. Each setting option indicates a setting that will be applied by the sender.  <ins> One CSM MUST be sent by each endpoint at the start of the connection. Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </ins> Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined  <ins> in Section 12.2 of RFC7252.  (The policy is analogous rather than identical because the structure of the subregistry includes an additional column; however, the value of this column has no influence on the policy.) </ins> The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following


The RFC7252 was designed for Internet of Things (IoT) deployments, assuming that UDP RFC0768 and DTLS RFC6347 over UDP can be used <del> unimpeded. The use of CoAP over UDP is focused on simplicity, has a low code footprint, and a small over-the-wire message size.  However, it also suffers from a few limitations: CoAP over UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture.  It is less well suited for transferring larger payloads, such as firmware updates.  For this reason blockwise transfer was added to CoAP, see RFC7959.  With blockwise transfer large data payloads get "chunked" into small(er) blocks and transferred individually. This also allows to suspend a transmission and to continue at a later time to interleave other, more urgent transmissions. CoAP over UDP offers a simple congestion control mechanism only. It uses an exponential backoff strategy for retransmissions and clients must strictly limit the number of simultaneous outstanding interactions to a given server to one.  This means that CoAP clients cannot send multiple concurrent requests to a single CoAP server.  A client will therefore have to wait till the outstanding interaction has been concluded.  When a larger transfer has been started, such as a firmware download, then this transfer will block other exchanges.  This is called "head-of-line blocking". Note that there is ongoing work to add more elaborate congestion control to CoAP as well, see I-D.ietf-core-cocoa. CoAP over UDP does not provide fragmentation and reassembly support but instead relies on lower layers to provide this functionality, such as IP or by an adaption layer, like 6lowpan. Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger data payloads would be possible up to the maximum size of the underlying datagram protocol.  With UDP the length field is 16 bit long, which leads to a maximum payload size of a little less than 64 Kbyte (due to the header size).  For firmware images 64 Kbyte may, however, be too small and relying on IP layer fragmentation is inefficient.  Any transmission larger than the path MTU will lead to IP fragmentation.  The path MTU needs to be determined first and it may change over time. Some networks drop UDP packets.  Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to EK2016.  UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity.  Some networks also rate-limit UDP traffic, as reported in BK2015.  QUIC deployment investigations revealed numbers around 0.3 % SW2016. Where NATs are present, CoAP over TCP can help with their traversal.  NATs often calculate expiration timers based on the transport layer protocol being used by application protocols. Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session life cycle.  UDP, on the other hand, does not provide such information to a NAT and </del>  timeouts tend to be much shorter HomeGateway.  According to HomeGateway the mean between TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP).  Shorter timeout values <del> require keepalive messages to be sent more more frequently. </del>  Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments <del> in existing CoAP implementations and deployments.  Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. </del>  Currently, there are also fewer HTTP/2 implementations available for <del> constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets.  For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP. (Note that both for a reliable transport and the CoAP over UDP message layer, the reliability offered is per transport hop: where proxies -- see Sections 5.7 and 10 of RFC7252 -- are involved, that layer's reliability function does not extend end-to-end.) fig- layering illustrates the layering: Note, however, that the use of CoAP over UDP (and CoAP over DTLS over UDP) is still the recommended transport for use constrained node networks, particularly when used in concert with blockwise transport. CoAP over TCP (and CoAP over TLS over TCP) is applicable for those cases where the networking infrastructure leaves no other choice. The use of CoAP over TCP leads to a larger code size, more roundtrips, increased RAM requirements and larger packet sizes. Developers are encouraged to read I-D.gomez-lwig-tcp-constrained- node-networks for guidance on low-footprint TCP implementations for IoT devices. CoAP may be integrated into a Web environment where the front-end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services.  A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device. To allow IoT devices to better communicate in these demanding environments, CoAP needs to support different transport protocols, namely TCP RFC0793, in some situations secured by TLS RFC5246. CoAP applications running inside a web browser without access to connectivity other than HTTP and the RFC6455 may cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-proxy or transport them via the the WebSocket protocol, which provides two-way </del>  communication between a WebSocket client and a WebSocket server after upgrading an RFC7230 connection.  This document specifies how to access resources using CoAP requests and responses over the TCP, TLS and WebSocket protocols.  This allows connectivity-limited applications to obtain end-to-end CoAP

This new version of the introduction focuses on the main reason for introducing CoAP over TCP, namely the problem encountered with enterprise firewalls. It provides references to data about how often such problems occur in the wild. I removed the other differences between CoAP over UDP and TCP since they appear to be secondary and a distraction.

The RFC7252 was designed for Internet of Things (IoT) deployments, assuming that UDP RFC0768 and DTLS RFC6347 over UDP can be used  <ins> unimpeded.  The use of CoAP over UDP is focused on simplicity, has a low code footprint, and a small over-the-wire message size. The primary reason for introducing CoAP over TCP RFC0793 and TLS RFC5246 is that some networks drop UDP packets.  Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to EK2016.  UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity.  Some networks also rate-limit UDP traffic, as reported in BK2015 and deployment investigations related to the standardization of QUIC revealed numbers around 0.3 % SW2016. The introduction of CoAP over TCP also leads to some side effects, namely Where NATs are present along the communication path, CoAP over TCP leads to different NAT traversal behavior than CoAP over UDP. NATs often calculate expiration timers based on the transport layer protocol being used by application protocols.  Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session lifecycle.  UDP, on the other hand, does not provide such information to a NAT and </ins> timeouts tend to be much shorter HomeGateway.  According to HomeGateway the mean between TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP).  Shorter timeout values  <ins> require keepalive messages to be sent more frequently.  Hence, the use of CoAP over TCP requires less frequent transmission of keep- alive messages. TCP utilizes more sophisticated congestion and flow control mechanisms, which is useful for the transfer of larger payloads. In the context of IoT deployments, such transfers could be firmware updates.  There is, however, ongoing work to add advanced congestion control to CoAP as well, see I-D.ietf-core-cocoa. Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is still the recommended transport for use constrained node networks, particularly when used in concert with blockwise transfer.  CoAP over TCP is applicable for those cases where the networking infrastructure leaves no other choice.  The use of CoAP over TCP leads to a larger code size, more roundtrips, increased RAM requirements and larger packet sizes.  Developers implementing CoAP over TCP are encouraged to read I-D.gomez-lwig-tcp-constrained-node-networks for guidance on low-footprint TCP implementations for IoT devices. </ins> Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments  <ins> in existing CoAP implementations and deployments. Although HTTP/2 could also potentially address the need for enterprise firewall traversal, there would be additional costs and delays introduced by such a transition from CoAP to HTTP/2. </ins> Currently, there are also fewer HTTP/2 implementations available for  <ins> constrained devices in comparison to CoAP.  Since CoAP also support group communication using IP layer multicast and unreliable communication IoT devices would have to support HTTP/2 in addition to CoAP. Furthermore, CoAP may be integrated into a Web environment where the front-end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services. A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device. Finally, CoAP applications running inside a web browser without access to connectivity other than HTTP and the RFC6455 may cross- proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-proxy or transport them via the the WebSocket protocol, which provides two-way </ins> communication between a WebSocket client and a WebSocket server after upgrading an RFC7230 connection. <ins> Finally, CoAP applications running inside a web browser may be without access to connectivity other than HTTP.  In this case, the WebSocket protocol RFC6455 may be used to either cross-proxy their CoAP requests via HTTP to an HTTP-to-CoAP cross-proxy or transport them via the WebSocket protocol.  This would, in turn, provide two- way communication between a WebSocket client and a WebSocket server after upgrading an HTTP/1.1 RFC7230 connection. To address the above-mentioned deployment requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets.  For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP.  (Note that both for a reliable transport and the CoAP over UDP message layer, the reliability offered is per transport hop: where proxies -- see Sections 5.7 and 10 of RFC7252 -- are involved, that layer's reliability function does not extend end-to-end.) fig-layering illustrates the layering: </ins> This document specifies how to access resources using CoAP requests and responses over the TCP, TLS and WebSocket protocols.  This allows connectivity-limited applications to obtain end-to-end CoAP


In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP introduces a length field with variable size. fig-frame shows the <del> adjusted CoAP header format with a modified structure for the fixed header (first 4 bytes of the UDP CoAP header), which </del>  includes the length information of variable size, shown here as an 8-bit length. first bit of the Options field.  Three values are reserved for special constructs: <del> An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. </del>  <del> A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. </del>  <del> A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </del>  <del> The encoding of the Len field is modeled on CoAP Options (see section 3.1 of RFC7252). </del>  <del> The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers. </del>  For example: A CoAP message just containing a 2.03 code with the token 7f and no options or payload would be encoded as shown in fig-

These labels are confusing and should be rewritten more in the style of RFC6455 with "Length" and "Extended Length" for clarity.
And remember to replace the last reference to: The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers.

In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP introduces a length field with variable size. fig-frame shows the  <ins> adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which </ins> includes the length information of variable size, shown here as an 8-bit length. first bit of the Options field.  Three values are reserved for special constructs:  <ins> An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13. </ins>  <ins> A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269. </ins>  <ins> A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </ins>  <ins> The encoding of the Length field is modeled on CoAP Options (see section 3.1 of RFC7252). </ins>  <ins> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </ins> For example: A CoAP message just containing a 2.03 code with the token 7f and no options or payload would be encoded as shown in fig-


2. <del> The request/response interaction model of CoAP TCP/TLS is the same as CoAP UDP.  The primary differences are in the message layer.  CoAP UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgement, and Reset.  TCP eliminates the need for the message layer to support reliability.  As a result, message types are not defined in CoAP TCP/TLS. </del>  2.1. <del> Conceptually, CoAP TCP/TLS replaces most of the CoAP UDP message layer with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that on datagram transports is provided by the UDP/DTLS datagram layer. </del>  <del> TCP ensures reliable message transmission, so the CoAP TCP/TLS </del>  messaging layer is not required to support acknowledgements or detection of duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the the individual messages separate and for providing length information. <del> The CoAP over TCP/TLS message format is very similar to the format </del>  specified for CoAP over UDP.  The differences are as follows: Since the underlying TCP connection provides retransmissions and 4.4. <del> In CoAP over TCP/TLS, Empty messages can always be sent and will be </del>  ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange.

I'm finding "CoAP over protocol" to be too verbose - especially in text that references or compares multiple protocol bindings. Can we agree on a shorthand? CoAP protocol such as CoAP UDP, CoAP TCP/TLS, CoAP WebSockets CoAP+protocol such as CoAP+UDP, CoAP+TCP/TLS, CoAP+WebSockets
The URI scheme component provides a reasonably good shorthand form to reflect the protocol bindings and the "Terminology" section could perhaps reflect that? It would be approximately lead to something like the following text: In this document, references to the various transport bindings for conveying CoAP messages adopt the following abbreviations: CoAP+TCP refers to CoAP over TCP, and CoAP+WS refers to CoAP over WebSockets. Using "CoAPS+" instead of "CoAP+" implies the use of their corresponding TLS-based secure counterparts. CoAP and CoAPS refer to CoAP over UDP and CoAP over DTLS, respectively.

2.  <ins> The request/response interaction model of CoAP over TCP is the same as CoAP over UDP.  The primary differences are in the message layer. CoAP over UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgement, and Reset. TCP eliminates the need for the message layer to support reliability. As a result, message types are not defined in CoAP over TCP. </ins> 2.1.  <ins> Conceptually, CoAP over TCP replaces most of the CoAP over UDP message layer with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that on datagram transports is provided by the UDP/DTLS datagram layer. </ins>  <ins> TCP ensures reliable message transmission, so the CoAP over TCP </ins> messaging layer is not required to support acknowledgements or detection of duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the the individual messages separate and for providing length information.  <ins> The CoAP over TCP message format is very similar to the format </ins> specified for CoAP over UDP.  The differences are as follows: Since the underlying TCP connection provides retransmissions and 4.4.  <ins> In CoAP over TCP, Empty messages can always be sent and will be </ins> ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange.


2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages after processing at the message layer.  For Confirmable (CON), Non-Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. </del>  2.3. requests and responses can be transferred in a block-wise fashion as defined in I-D.ietf-core-block. <del> Empty messages (Code 0.00) are ignored by the recipient (see also </del>  sec-ping). 3.3. Most CSM Options are useful mainly as initial messages in the connection. <del> Both capability and settings options are cumulative, i.e., a Capability and Settings message does not invalidate a previously made capability indication or setting even if that is not repeated, and a capability message without any option is a no-operation (and can be used as such).  An option that is given might override a previous value for the same option; the option defines how to handle this, if </del>  needed. <del> Default values given below for CSM Options are not default values for the option (this would mean that an empty Capability and Settings message would set the option back to its default value).  Instead they give the base value for the Capability and Setting before any Capability and Settings message sends a modified value. </del>  Capability and Settings messages are indicated by the 7.01 code (CSM). The sender can use the Max-Message-Size elective option to indicate the maximum message size in bytes that it can receive. <del> As per Section 4.6 of RFC7252, the default value (and the value used </del>  when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability. 4.4. <del> In CoAP over TCP, Empty messages can always be sent and will be ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del>  Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.

2.2.  <ins> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. </ins> 2.3. requests and responses can be transferred in a block-wise fashion as defined in I-D.ietf-core-block.  <ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also </ins> sec-ping). 3.3. Most CSM Options are useful mainly as initial messages in the connection.  <ins> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no-operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if </ins> needed.  <ins> Base values are listed below for CSM Options.  These are the values for the Capability and Setting before any Capability and Settings messages sends a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty Capability and Settings message would result in the option being set to its default value. </ins> Capability and Settings messages are indicated by the 7.01 code (CSM). The sender can use the Max-Message-Size elective option to indicate the maximum message size in bytes that it can receive.  <ins> As per Section 4.6 of RFC7252, the base value (and the value used </ins> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability. 4.4.  <ins> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the


The security considerations of RFC7252 apply. <del> Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS.  The general TLS usage guidance in RFC7525 SHOULD be followed. </del>  <del> Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </del>  TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by

Updated ietf-dice-profile reference to RFC7925
Issue was raised to see if we should consider making TLS a must instead of a recommendation. Since most of the motivation for either TCP or WebSocket is enterprise driven, security should also be required by the party using the technology.
It is currently neither (a MUST or even a recommendation), and I have no idea why it should be. If application layer security ("object security") is in use, there is no need for TLS. In other words, Security is not an option, but using TLS for security is. (It even is in HTTP/2...) (Same argument for coap+ws vs. coap+wss.)
I do not see extra effort when enabling TCP as transport. I only see possible issues when disabling TCP as an option by making TLS as must: TLS does not work across intermediaries, so mechanisms such as object security might become popular or even pre-dominant (wild guess!). The TLS handshake might just be an obstacle that wants to be avoided then. RD or discovery in general often assumes CoAP (without S) interactions (e.g., simple registration or public lookups) The benefit for adoption, testing, and debugging when encryption can be disabled. It helped a lot for normal CoAP and the nice thing is that once it works over TCP, it is rather trivial to enable security for production by switching to TLS. (The reason why most CoAP deployments did not use CoAPS for a long time was the lack of proper DTLS 1.2 implementations. We do not have this problem for TLS.) So: -1 for making TLS a must +1 for keeping TCP
There was no interest in eliminating TCP. Zach's suggested language - TLS is mandatory to implement and on by default. Also should compare guidance in
Reopening to track potential WGLC discussion - URL
Summarizing, with my words, the latest mail duscussion on the list regarding this sentence: "TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default." RFC7252 allows UDP or DTLS. Section 9 in RFC7252 specifies the binding to DTLS, and, given that binding, what is mandatory to implement (NoSec and RPK with a certain ciphersuite). The analogy would be that this draft specifies CoAP over TCP, the binding to TLS and what is mandatory to implement with this binding. (Göran) Considering that CoAP over TCP may be protected on other layers than transport layer, e.g. on application layer using OSCOAP, and that a constrained device may not be able to support multiple security protocol implementations, the statement about mandating implementation of TLS should be removed. OSCOAP was not adopted at the time when the previous discussion was held and was not sufficiently understood and considered in that discussion. (Göran) It is not clear what "on by default" means. Security is a process and unless people follow the process, "switching on security" in a protocol implementation isn't giving you any. (Carsten) What does "use TLS" mean on a constrained device? I do not believe this question should be answered in the CoAP-over-TLS draft; security processes for IoT are a subject of active research, not something where we have enough solid knowledge for an MTI. (Carsten) I guess you are saying that CoAP itself is a building block and the way how IoT is used today it does not really make any sense to talk about randomly plugging things together. (Hannes) Indeed, and that means to me that "on by default", which would mean some such random plugging, is not we what can seriously recommend. (Carsten)
Doing the analogous for coap-over-tcp (and TLS) sounds very reasonable to me. In particular because there are many implementations of TLS available (as opposed to DTLS as Matthias pointed out), I don't think that it is sufficient to say "TLS must be implemented". If the spec makes TLS mandatory (to implement or/and to enable by default) it should also define which cipher suites are mandatory to implement. This is of practical importance in particular to constrained devices which probably cannot do the same sort of RSA based security as e.g. gateway components can ...
URL There are several MUSTs in that document. Do we want to turn them into SHOULDs? No. -> The TLS usage guidance in [RFC7925] applies.
Shared proposal on the mailing list - URL
CoAP MUST NOT be used with older versions of TLS. Guidelines for use of cipher suites and TLS extensions can be found in {{I-D.ietf-dice-profile}}. This should be phrased in the positive: Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed ... What is the appropriate behavior when an older version is used? For example, compare with for possible connection errors and further TLS 1.2 restrictions. An endpoint MAY immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a connection error of type INADEQUATESECURITY._
One interesting question is how TLS libraries export that functionality -- can a listener be configured to only allow 1.2+? Is the actual protocol chosen signaled up?
URL
URL
This may a case where an Inadequate-Security option could be added to Abort (Signaling)?
Right. Generally we should create machinery only where the recipient of some information can react to it in a programmatic way. I don't expect a client to be automatically able to set up a new connection with a better TLS version upon reception of such an Inadequate-Security option. So I think this is better handled in a diagnostic payload, which we don't need to standardize.

The security considerations of RFC7252 apply.  <ins> TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over TLS connection that does not meet this requirement (see sec-abort) and SHOULD include a diagnostic payload. </ins>  <ins> The TLS usage guidance in RFC7925 SHOULD be followed. </ins> TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by


it. To check the health of the WebSocket connection (and thereby of all <del> active requests, if any), the client can send a Ping frame or an unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There is no way to retransmit a request without creating a new one.  Re- registering interest in a resource is permitted, but entirely </del>  unnecessary. 3.5. 4.4. In CoAP over TCP, Empty messages (Code 0.00) can always be sent and <del> MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del>  Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

There needs to be guidance about the intersection of WebSocket Ping-Pong and Signaling Ping-Pong.
Since Signaling Ping-Pong is a superset of WebSockets Ping-Pong and to use a consistent mechanism across reliable transports, I will add guidance that Signaling Ping-Pong is preferred over WebSockets Ping-Pong.

it. To check the health of the WebSocket connection (and thereby of all  <ins> active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely </ins> unnecessary. 3.5. 4.4. In CoAP over TCP, Empty messages (Code 0.00) can always be sent and  <ins> MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the


CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. <del> To address such environments, this document defines how to transport </del>  CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering: This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252.  A Block1 or Block2 option that includes an SZX value of 7. CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP <del> and CoAP over reliable transport.  The removed Type (no type) and Message ID fields are indicated by dashes. </del>  2.2.

Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.

CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets.  <ins> Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments.  Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport </ins> CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering: This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. <ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP. </ins> A Block1 or Block2 option that includes an SZX value of 7. CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP  <ins> and CoAP over reliable transport.  The removed Type and Message ID fields are indicated by dashes. </ins> 2.2.


The payload of a CoAP message that is affected by a BERT Option in <del> descriptive usage (Section 2.1 of I-D.ietf-core-block). </del>  2. WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as <del> defined in I-D.ietf-core-block. </del>  Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). 4.3.3. A sender can use the Block-wise Transfer elective Option to indicate <del> that it supports the block-wise transfer protocol I-D.ietf-core- block. </del>  If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block- <del> wise transfer protocol I-D.ietf-core-block is also no longer needed, it remains applicable for a number of cases: </del>  large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved <del> value in I-D.ietf-core-block. </del>  In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the

There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.

The payload of a CoAP message that is affected by a BERT Option in  <ins> descriptive usage (Section 2.1 of RFC7959). </ins> 2. WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as  <ins> defined in RFC7959. </ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). 4.3.3. A sender can use the Block-wise Transfer elective Option to indicate  <ins> that it supports the block-wise transfer protocol RFC7959. </ins> If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block-  <ins> wise transfer protocol RFC7959 is also no longer needed, it remains applicable for a number of cases: </ins> large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved  <ins> value in RFC7959. </ins> In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the


transfers.  The absence of options in the CSM indicates that base values are assumed.  Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). this server. The Alternative-Address elective option requests the peer to instead <del> open a connection of the same kind as the present connection to the </del>  alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.

Also clarifies that "same kind" in Alternate-Address refers to scheme.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?
NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.

transfers.  The absence of options in the CSM indicates that base values are assumed. <ins> 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). </ins> Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). this server. The Alternative-Address elective option requests the peer to instead  <ins> open a connection of the same scheme as the present connection to the </ins> alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.


<del> A TCP and TLS Transport for the Constrained Application Protocol (CoAP) </del>  draft-ietf-core-coap-tcp-tls-latest Abstract <del> The Hypertext Transfer Protocol (HTTP) was designed with TCP as the underlying transport protocol.  The Constrained Application Protocol (CoAP), while inspired by HTTP, has been defined to make use of UDP instead of TCP.  Therefore, reliable delivery and a simple congestion control and flow control mechanism are provided by the message layer of the CoAP protocol. </del>  <del> A number of environments benefit from the use of CoAP directly over a reliable byte stream such as TCP, which already provides these services.  This document defines the use of CoAP over TCP as well as CoAP over TLS. </del>  1. The RFC7252 was designed for Internet of Things (IoT) deployments, <del> assuming that UDP can be used unimpeded -- UDP RFC0768, or DTLS RFC6347 over UDP; it is a good choice for transferring small amounts of data across networks that follow the IP architecture.  Some CoAP deployments, however, may have to integrate well with existing enterprise infrastructure, where the use of UDP-based protocols may not be well-received or may even be blocked by firewalls. Middleboxes that are unaware of CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. Where NATs are still present, CoAP over TCP can also help with their traversal.  NATs often calculate expiration timers based on the transport layer protocol being used by application protocols.  Many NATs are built around the assumption that a transport layer protocol, such as TCP, gives them additional information about the session life cycle and keep TCP-based NAT bindings around for a longer period. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter, as research confirms HomeGateway. </del>  Some environments may also benefit from the ability of TCP to exchange larger payloads (such as firmware images) without application layer segmentation and to utilize the more sophisticated congestion control capabilities provided by many TCP implementations. (Note that there is ongoing work to add more elaborate congestion control to CoAP as well, see I-D.bormann-core-cocoa.) <del> Finally, CoAP may be integrated into a Web environment where the front-end uses CoAP from IoT devices to a cloud infrastructure but the CoAP messages are then transported in TCP between the back-end services.  A TCP-to-UDP gateway can be used at the cloud boundary to talk to the UDP-based IoT. </del>  To make IoT devices work smoothly in these demanding environments, CoAP needs to make use of a different transport protocol, namely TCP RFC0793, in some situations secured by TLS RFC5246. <del> Conceptually, the CoAP over TCP/TLS specification replaces most of CoAP's message layer by a new message adapter on top of TCP or TLS that does provides a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information about each CoAP message that on datagram transports is provided by the datagram layer below (UDP, DTLS). The message adapter also adds a way to use signaling messages to perform various housekeeping operations on the TCP, see [I-D.bormann- core-signaling]. When CoAP is used over TLS then some of the housekeeping features are already available with the TLS Handshake protocol; less new functionality is then required. Modifications to CoAP beyond the replacement of the message layer (e.g., to introduce further optimizations) are intentionally avoided. 2. </del>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 3. </del>  The interaction model of CoAP over TCP is very similar to the one for CoAP over UDP, with the key difference that using TCP voids the need A response is sent back as defined in RFC7252, as illustrated in fig- untyped2 (derived from RFC7252, Figure 6). <del> 4. </del>  The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged. <del> 4.1. One observation is that, over a reliable byte stream transport, the message size limitations defined in Section 4.6 of RFC7252 are no longer strictly necessary.  Consenting [[how: There is currently no defined way to arrive at this consent. --cabo]] implementations may want to interchange messages with payload sizes larger than 1024 bytes, potentially also obviating the need for the Block protocol I- D.ietf-core-block.  It must be noted that entirely getting rid of the block protocol is not a generally applicable solution, as: a UDP-to-TCP gateway may simply not have the context to convert a message with a Block option into the equivalent exchange without any use of a Block option; large messages might also cause undesired head-of-line blocking; the 2-byte message length field causes another, larger upper bound to the message length. I-D.bormann-core-block-bert proposes to extend the block-wise transfer protocol to allow for larger block sizes as are possible over TCP and TLS. </del>  <del> The general assumption is therefore that the block protocol will continue to be used over TCP, even if TCP-based applications occasionally do exchange messages with payload sizes larger than desirable in UDP. 5. </del>  As CoAP exchanges messages asynchronously over the TCP connection, the client can send multiple requests without waiting for responses. connection has no bearing on the meaning of the CoAP terms client and server. <del> 6. </del>  <del> CoAP RFC7252 defines the "coap" and "coaps" URI schemes for </del>  identifying CoAP resources and providing a means of locating the <del> resource.  RFC 7252 defines these resources for use with CoAP over UDP. </del>  <del> The present specification introduces two new URI schemes, namely "coap+tcp" and "coaps+tcp".  The rules from Section 6 of RFC7252 apply to these two new URI schemes. </del>  <del> RFC7252, Section 8 (Multicast CoAP), does not apply to the URI schemes defined in the present specification. </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 schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers. <del> 6.1. </del>  The semantics defined in RFC7252, Section 6.1, apply to this URI scheme, with the following changes: server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.) <del> 6.2. </del>  The semantics defined in RFC7252, Section 6.2, apply to this URI scheme, with the following changes: Layer Protocol Negotiation Extension" RFC7301 MUST be used to allow demultiplexing at the server-side. <del> 7. </del>  <del> This document defines how to convey CoAP over TCP and TLS.  CoAP RFC7252 makes use of DTLS 1.2 and this specification consequently uses TLS 1.2 RFC5246.  CoAP MUST NOT be used with older versions of TLS.  Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </del>  TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by spoofing a TCP reset message. <del> 8. </del>  <del> 8.1. </del>  IANA is requested to assign the port number 5683 and the service name "coap+tcp", in accordance with RFC6335. 443 (see also alpnpid of [RFCthis]}) <del> 8.2. </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 IANA is requested to add these new URI schemes to the registry established with RFC7595. <del> 8.3. </del>  IANA is requested to assign the following value in the registry "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created [RFCthis]

This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with

<ins> CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets </ins> draft-ietf-core-coap-tcp-tls-latest Abstract  <ins> The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of the CoAP over UDP protocol includes services for reliable delivery, simple congestion control, and flow control. </ins>  <ins> Some environments would benefit from the availability of CoAP over a reliable transport such as TCP or WebSockets, which already provides such services.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. </ins> 1. The RFC7252 was designed for Internet of Things (IoT) deployments,  <ins> assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received or may even be blocked by firewalls.  Middleboxes that are unaware of CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. To address such environments, this document defines additional bindings for CoAP, including TCP, TLS, and WebSockets. Where NATs are present, CoAP over TCP can help with their traversal. NATs often calculate expiration timers based on the transport layer protocol being used by application protocols.  Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session life cycle.  UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter, as confirmed by research HomeGateway. </ins> Some environments may also benefit from the ability of TCP to exchange larger payloads (such as firmware images) without application layer segmentation and to utilize the more sophisticated congestion control capabilities provided by many TCP implementations. (Note that there is ongoing work to add more elaborate congestion control to CoAP as well, see I-D.bormann-core-cocoa.)  <ins> CoAP may be integrated into a Web environment where the front-end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services.  A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device. </ins> To make IoT devices work smoothly in these demanding environments, CoAP needs to make use of a different transport protocol, namely TCP RFC0793, in some situations secured by TLS RFC5246.  <ins> Some corporate networks only allow Internet access via a HTTP proxy. In this case, the best transport for CoAP would 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. This document specifies how to access resources using CoAP requests and responses over the WebSocket Protocol.  This allows connectivity- limited applications to obtain end-to-end CoAP connectivity either by communicating CoAP directly with a CoAP server accessible over a WebSocket Connection or via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. 1.1. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.  <ins> This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. 2. </ins> The interaction model of CoAP over TCP is very similar to the one for CoAP over UDP, with the key difference that using TCP voids the need A response is sent back as defined in RFC7252, as illustrated in fig- untyped2 (derived from RFC7252, Figure 6).  <ins> EDITOR: These are "leftover" paragraphs from the original Overview section.  Keeping until I perform a complete editorial pass of the "roughed in" material. Conceptually, the CoAP over TCP/TLS specification replaces most of CoAP's message layer by a new message adapter on top of TCP or TLS that provides a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information about each CoAP message that on datagram transports is provided by the datagram layer below (UDP, DTLS). The message adapter also adds a way to use signaling messages to perform various housekeeping operations on the TCP, see [I-D.bormann- core-signaling]. When CoAP is used over TLS then some of the housekeeping features are already available with the TLS Handshake protocol; less new functionality is then required. Modifications to CoAP beyond the replacement of the message layer (e.g., to introduce further optimizations) are intentionally avoided. 2.1. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged.  <ins> 2.2. </ins>  <ins> EDITOR: This is extremely similar to the WebSocket section of the same name. </ins> As CoAP exchanges messages asynchronously over the TCP connection, the client can send multiple requests without waiting for responses. connection has no bearing on the meaning of the CoAP terms client and server.  <ins> 3. </ins>  <ins> CoAP over WebSockets can be used in a number of configurations.  The most basic configuration is a CoAP client seeking to retrieve or update a CoAP resource located at a CoAP server that exposes a WebSocket endpoint (arch-1).  The CoAP client takes the role of the WebSocket client, establishes a WebSocket Connection and sends a CoAP request, to which the CoAP server returns a CoAP response.  The WebSocket Connection can be used for any number of requests. The challenge in this configuration is to identify 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 that the client is able to determine 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 proposes a new "coap+ws" URI scheme that identifies both a WebSocket endpoint and a resource within that endpoint as follows: 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. A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket endpoint and is then reachable through the WebSocket server.  When no connection exists, the CoAP server is not reachable; it therefore can be considered a I-D.dijk-core-sleepy-reqs.  Because the WebSocket server is the only way to reach the CoAP server, the CoAP proxy should be a Reverse Proxy. Further configurations are possible, including those where a WebSocket Connection is established through an HTTP proxy. CoAP over WebSockets is intentionally very similar to CoAP as defined over UDP.  Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. 3.1. Before CoAP requests and responses can be exchanged, a WebSocket Connection needs to be established as defined in Section 4 of RFC6455. handshake-example shows an example. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined in this document.  Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server. 3.2. Once a WebSocket Connection has been established, CoAP requests and responses can be exchanged as WebSocket messages.  Since CoAP uses a binary message format, the messages are transmitted in binary data frames as specified in Sections 5 and 6 of RFC6455. The message format is very similar to the format specified for RFC7252.  The differences are as follows: Since the underlying TCP connection provides retransmissions and deduplication, there is no need for the reliability mechanisms provided by CoAP over UDP.  This means the "T" and "Message ID" fields in the CoAP message header can be elided. Furthermore, since the CoAP version is already negotiated during the opening handshake, the "Ver" field can be elided as well. The resulting message format is shown in ws-message-format.  The four most-significant bits of the first byte are reserved (R) and MUST be set to zero.  The remaining fields and structure are the same as defined in RFC7252. Requests and response messages can be fragmented as specified in Section 5.4 of RFC6455, though typically they are sent unfragmented as they tend to be small and fully buffered before transmission.  The WebSocket protocol does not provide means for multiplexing; if it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a blockwise fashion as defined in I-D.ietf-core-block. Messages MUST NOT be Empty (Code 0.00), i.e., messages always carry either a request or a response. 3.3. CoAP requests and responses are exchanged asynchronously over the WebSocket Connection, i.e., a CoAP client can send multiple requests without waiting for a response and the CoAP server can return responses in any order.  Responses MUST be returned over the same connection as the originating request.  Concurrent requests are differentiated by their Token, which is scoped locally to the connection. The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. Retransmission and deduplication of messages is provided by the WebSocket Protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. Since the WebSocket Protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. 3.4. When 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), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket Connection (and thereby of all active requests, if any), the client can send a Ping frame or an unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There is no way to retransmit a request without creating a new one.  Re- registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket Connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed.  If the client observes one or more resources over the WebSocket Connection, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client from the lists of observers when the connection is closed. 4. CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for </ins> identifying CoAP resources and providing a means of locating the  <ins> resource. 4.1. </ins>  <ins> CoAP over TCP uses "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. </ins>  <ins> RFC7252, Section 8 (Multicast CoAP) is not applicable to these schemes. </ins> Resources made available via one of the "coap+tcp" or "coaps+tcp" schemes have no shared identity with the other scheme or with the schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers.  <ins> 4.1.1. </ins> The semantics defined in RFC7252, Section 6.1, apply to this URI scheme, with the following changes: server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.)  <ins> 4.1.2. </ins> The semantics defined in RFC7252, Section 6.2, apply to this URI scheme, with the following changes: Layer Protocol Negotiation Extension" RFC7301 MUST be used to allow demultiplexing at the server-side.  <ins> 4.2. For the first configuration discussed in 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. </ins>  <ins> 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 the CoAP protocol. 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. 4.2.1. 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: 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. 5. Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS.  The general TLS usage guidance in RFC7525 SHOULD be followed. Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </ins> TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by spoofing a TCP reset message.  <ins> CoAP over WebSockets and CoAP over TLS-secured WebSockets do not introduce additional security issues beyond CoAP and DTLS-secured CoAP respectively RFC7252.  The security considerations of RFC6455 apply. </ins>  <ins> 6. 6.1. </ins> IANA is requested to assign the port number 5683 and the service name "coap+tcp", in accordance with RFC6335. 443 (see also alpnpid of [RFCthis]})  <ins> 6.2. </ins> 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 IANA is requested to add these new URI schemes to the registry established with RFC7595.  <ins> 6.2.1. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+ws".  The registration request complies with RFC4395. coap+ws Permanent Defined in Section N of [RFCthis] 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. 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. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.2.2. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+wss".  The registration request complies with RFC4395. coap+wss Permanent Defined in Section N of [RFCthis] 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). 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. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.3. IANA is requested to register the 'coap' well-known URI in the "Well- Known URIs" registry.  This registration request complies with RFC5785: coap IETF [RFCthis] None. 6.4. </ins> IANA is requested to assign the following value in the registry "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created [RFCthis] <ins> 6.5. IANA is requested to register the WebSocket CoAP subprotocol under the "WebSocket Subprotocol Name Registry": coap Constrained Application Protocol (CoAP) [RFCthis] </ins>


message that on datagram transports is provided by the UDP/DTLS datagram layer. <del> TCP ensures reliable message transmission, so the CoAP over TCP messaging layer is not required to support acknowledgements or to </del>  detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format. 2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. 2.3. </del> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). <del> 2.4. </del>  The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged. <del> 2.5. </del>  CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).

message that on datagram transports is provided by the UDP/DTLS datagram layer.  <ins> TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support acknowledgements or to </ins> detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format. 2.2.  Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort).  <ins> 2.3. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged.  <ins> 2.4. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without