idnits 2.17.1 draft-ietf-core-coap-tcp-tls-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7959, but the abstract doesn't seem to directly say this. It does mention RFC7959 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2017) is 2326 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0xbc90' is mentioned on line 350, but not defined == Missing Reference: '------' is mentioned on line 350, but not defined == Missing Reference: 'RFCthis' is mentioned on line 1904, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-03) exists of draft-ietf-core-cocoa-02 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Updates: 7641, 7959 (if approved) S. Lemay 5 Intended status: Standards Track Zebra Technologies 6 Expires: June 21, 2018 H. Tschofenig 7 ARM Ltd. 8 K. Hartke 9 Universitaet Bremen TZI 10 B. Silverajan 11 Tampere University of Technology 12 B. Raymor, Ed. 13 December 18, 2017 15 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets 16 draft-ietf-core-coap-tcp-tls-11 18 Abstract 20 The Constrained Application Protocol (CoAP), although inspired by 21 HTTP, was designed to use UDP instead of TCP. The message layer of 22 the CoAP over UDP protocol includes support for reliable delivery, 23 simple congestion control, and flow control. 25 Some environments benefit from the availability of CoAP carried over 26 reliable transports such as TCP or TLS. This document outlines the 27 changes required to use CoAP over TCP, TLS, and WebSockets 28 transports. It also formally updates RFC 7641 for use with these 29 transports and RFC 7959 to enable the use of larger messages over a 30 reliable transport. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 21, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 68 3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 8 71 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 10 72 3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 11 73 4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12 74 4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 13 75 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14 76 4.3. Message Transmission . . . . . . . . . . . . . . . . . . 15 77 4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 15 78 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16 80 5.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16 81 5.3. Capabilities and Settings Messages (CSM) . . . . . . . . 16 82 5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 19 83 5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 20 84 5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 21 85 5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 22 86 6. Block-wise Transfer and Reliable Transports . . . . . . . . . 23 87 6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 24 88 6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 25 89 7. Observing Resources over Reliable Transports . . . . . . . . 25 90 7.1. Notifications and Reordering . . . . . . . . . . . . . . 26 91 7.2. Transmission and Acknowledgements . . . . . . . . . . . . 26 92 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 26 93 7.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 27 94 8. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 27 95 8.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 28 96 8.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 28 97 8.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 29 98 8.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 30 99 8.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 31 100 8.6. Decomposing URIs into Options . . . . . . . . . . . . . . 31 101 8.7. Composing URIs from Options . . . . . . . . . . . . . . . 32 102 9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 32 103 9.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 33 104 9.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 34 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 106 10.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 34 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 108 11.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 34 109 11.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 35 110 11.3. Service Name and Port Number Registration . . . . . . . 36 111 11.4. Secure Service Name and Port Number Registration . . . . 37 112 11.5. URI Scheme Registration . . . . . . . . . . . . . . . . 38 113 11.6. Well-Known URI Suffix Registration . . . . . . . . . . . 40 114 11.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 40 115 11.8. WebSocket Subprotocol Registration . . . . . . . . . . . 40 116 11.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 41 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 41 119 12.2. Informative References . . . . . . . . . . . . . . . . . 43 120 Appendix A. CoAP over WebSocket Examples . . . . . . . . . . . . 45 121 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48 122 B.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 48 123 B.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 48 124 B.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 48 125 B.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 48 126 B.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 49 127 B.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 49 128 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49 129 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 132 1. Introduction 134 The Constrained Application Protocol (CoAP) [RFC7252] was designed 135 for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] 136 can be used unimpeded, as can the Datagram Transport Layer Security 137 protocol (DTLS [RFC6347]) over UDP. The use of CoAP over UDP is 138 focused on simplicity, has a low code footprint, and a small over- 139 the-wire message size. 141 The primary reason for introducing CoAP over TCP [RFC0793] and TLS 142 [RFC5246] is that some networks do not forward UDP packets. Complete 143 blocking of UDP happens in between about 2% and 4% of terrestrial 144 access networks, according to [EK2016]. UDP impairment is especially 145 concentrated in enterprise networks and networks in geographic 146 regions with otherwise challenged connectivity. Some networks also 147 rate-limit UDP traffic, as reported in [BK2015] and deployment 148 investigations related to the standardization of QUIC revealed 149 numbers around 0.3 % [SW2016]. 151 The introduction of CoAP over TCP also leads to some additional 152 effects that may be desirable in a specific deployment: 154 o Where NATs are present along the communication path, CoAP over TCP 155 leads to different NAT traversal behavior than CoAP over UDP. 156 NATs often calculate expiration timers based on the transport 157 layer protocol being used by application protocols. Many NATs 158 maintain TCP-based NAT bindings for longer periods based on the 159 assumption that a transport layer protocol, such as TCP, offers 160 additional information about the session lifecycle. UDP, on the 161 other hand, does not provide such information to a NAT and 162 timeouts tend to be much shorter [HomeGateway]. According to 163 [HomeGateway] the mean for TCP and UDP NAT binding timeouts is 386 164 minutes (TCP) and 160 seconds (UDP). Shorter timeout values 165 require keepalive messages to be sent more frequently. Hence, the 166 use of CoAP over TCP requires less frequent transmission of keep- 167 alive messages. 169 o TCP utilizes more sophisticated congestion and flow control 170 mechanisms than the default mechanisms provided by CoAP over UDP, 171 which is useful for the transfer of larger payloads. (Work is, 172 however, ongoing to add advanced congestion control to CoAP over 173 UDP as well, see [I-D.ietf-core-cocoa].) 175 Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is 176 still the recommended transport for use in constrained node networks, 177 particularly when used in concert with blockwise transfer. CoAP over 178 TCP is applicable for those cases where the networking infrastructure 179 leaves no other choice. The use of CoAP over TCP leads to a larger 180 code size, more roundtrips, increased RAM requirements and larger 181 packet sizes. Developers implementing CoAP over TCP are encouraged 182 to consult [I-D.gomez-lwig-tcp-constrained-node-networks] for 183 guidance on low-footprint TCP implementations for IoT devices. 185 Standards based on CoAP such as Lightweight Machine to Machine 186 [LWM2M] currently use CoAP over UDP as a transport; adding support 187 for CoAP over TCP enables them to address the issues above for 188 specific deployments and to protect investments in existing CoAP 189 implementations and deployments. 191 Although HTTP/2 could also potentially address the need for 192 enterprise firewall traversal, there would be additional costs and 193 delays introduced by such a transition from CoAP to HTTP/2. 194 Currently, there are also fewer HTTP/2 implementations available for 195 constrained devices in comparison to CoAP. Since CoAP also support 196 group communication using IP layer multicast and unreliable 197 communication IoT devices would have to support HTTP/2 in addition to 198 CoAP. 200 Furthermore, CoAP may be integrated into a Web environment where the 201 front-end uses CoAP over UDP from IoT devices to a cloud 202 infrastructure and then CoAP over TCP between the back-end services. 203 A TCP-to-UDP gateway can be used at the cloud boundary to communicate 204 with the UDP-based IoT device. 206 Finally, CoAP applications running inside a web browser may be 207 without access to connectivity other than HTTP. In this case, the 208 WebSocket protocol [RFC6455] may be used to transport CoAP requests 209 and responses, as opposed to cross-proxying them via HTTP to an HTTP- 210 to-CoAP cross-proxy. This preserves the functionality of CoAP 211 without translation, in particular the Observe mechanism [RFC7641]. 213 To address the above-mentioned deployment requirements, this document 214 defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over 215 WebSockets. For these cases, the reliability offered by the 216 transport protocol subsumes the reliability functions of the message 217 layer used for CoAP over UDP. (Note that both for a reliable 218 transport and the CoAP over UDP message layer, the reliability 219 offered is per transport hop: where proxies -- see Sections 5.7 and 220 10 of [RFC7252] -- are involved, that layer's reliability function 221 does not extend end-to-end.) Figure 1 illustrates the layering: 223 +--------------------------------+ 224 | Application | 225 +--------------------------------+ 226 +--------------------------------+ 227 | Requests/Responses/Signaling | CoAP (RFC 7252) / This Document 228 |--------------------------------| 229 | Message Framing | This Document 230 +--------------------------------+ 231 | Reliable Transport | 232 +--------------------------------+ 234 Figure 1: Layering of CoAP over Reliable Transports 236 This document specifies how to access resources using CoAP requests 237 and responses over the TCP, TLS and WebSocket protocols. This allows 238 connectivity-limited applications to obtain end-to-end CoAP 239 connectivity either by communicating CoAP directly with a CoAP server 240 accessible over a TCP, TLS or WebSocket connection or via a CoAP 241 intermediary that proxies CoAP requests and responses between 242 different transports, such as between WebSockets and UDP. 244 Section 7 updates the "Observing Resources in the Constrained 245 Application Protocol" [RFC7641] specification for use with CoAP over 246 reliable transports. [RFC7641] is an extension to the CoAP protocol 247 that enables CoAP clients to "observe" a resource on a CoAP server. 248 (The CoAP client retrieves a representation of a resource and 249 registers to be notified by the CoAP server when the representation 250 is updated.) 252 2. Conventions and Terminology 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in 257 [RFC2119]. 259 This document assumes that readers are familiar with the terms and 260 concepts that are used in [RFC6455], [RFC7252], [RFC7641], and 261 [RFC7959]. 263 The term "reliable transport" is used only to refer to transport 264 protocols, such as TCP, which provide reliable and ordered delivery 265 of a byte-stream. 267 Block-wise Extension for Reliable Transport (BERT): 268 BERT extends [RFC7959] to enable the use of larger messages over a 269 reliable transport. 271 BERT Option: 272 A Block1 or Block2 option that includes an SZX value of 7. 274 BERT Block: 275 The payload of a CoAP message that is affected by a BERT Option in 276 descriptive usage (see Section 2.1 of [RFC7959]). 278 Transport Connection: 279 Underlying reliable byte stream connection, as directly provided 280 by TCP, or indirectly via TLS or WebSockets. 282 Connection: 283 Transport Connection, unless explicitly qualified otherwise. 285 Connection Initiator: 286 The peer that opens a Transport Connection, i.e., the TCP active 287 opener, TLS client, or WebSocket client. 289 Connection Acceptor: 290 The peer that accepts the Transport Connection opened by the other 291 peer, i.e., the TCP passive opener, TLS server, or WebSocket 292 server. 294 3. CoAP over TCP 296 The request/response interaction model of CoAP over TCP is the same 297 as CoAP over UDP. The primary differences are in the message layer. 298 The message layer of CoAP over UDP supports optional reliability by 299 defining four types of messages: Confirmable, Non-confirmable, 300 Acknowledgement, and Reset. In addition, messages include a Message 301 ID to relate Acknowledgments to Confirmable messages and to detect 302 duplicate messages. 304 The management of the transport connections is left to the 305 application, i.e., the present specification does not describe how an 306 application decides to open a connection or to re-open another one in 307 the presence of failures (or what it would deem to be a failure, see 308 also Section 5.4). In particular, the Connection Initiator need not 309 be the client of the first request placed on the connection. Some 310 implementations will want to implement a dynamic connection 311 management similar to the one described in Section 6 of [RFC7230] for 312 HTTP, opening a connection when the first client request is ready to 313 be sent and reusing that for further messages for a while, until no 314 message is sent for a certain time and no requests are outstanding 315 (possibly with a configurable idle time) and a release process is 316 started (Section 5.5). In implementations of this kind, connection 317 releases or aborts may not be indicated as errors to the application 318 but may simply be handled by automatic reconnection once the need 319 arises again. Other implementations may be based on configured 320 connections that are kept open continuously and lead to management 321 system notifications on release or abort. The protocol defined in 322 the present specification is intended to work with either model (or 323 other, application-specific connection management models). 325 3.1. Messaging Model 327 Conceptually, CoAP over TCP replaces most of the message layer of 328 CoAP over UDP with a framing mechanism on top of the byte-stream 329 provided by TCP/TLS, conveying the length information for each 330 message that on datagram transports is provided by the UDP/DTLS 331 datagram layer. 333 TCP ensures reliable message transmission, so the message layer of 334 CoAP over TCP is not required to support acknowledgements or to 335 detect duplicate messages. As a result, both the Type and Message ID 336 fields are no longer required and are removed from the CoAP over TCP 337 message format. 339 Figure 2 illustrates the difference between CoAP over UDP and CoAP 340 over reliable transport. The removed Type and Message ID fields are 341 indicated by dashes. 343 CoAP Client CoAP Server CoAP Client CoAP Server 344 | | | | 345 | CON [0xbc90] | | (-------) [------] | 346 | GET /temperature | | GET /temperature | 347 | (Token 0x71) | | (Token 0x71) | 348 +------------------->| +------------------->| 349 | | | | 350 | ACK [0xbc90] | | (-------) [------] | 351 | 2.05 Content | | 2.05 Content | 352 | (Token 0x71) | | (Token 0x71) | 353 | "22.5 C" | | "22.5 C" | 354 |<-------------------+ |<-------------------+ 355 | | | | 357 CoAP over UDP CoAP over reliable 358 transport 360 Figure 2: Comparison between CoAP over unreliable and reliable 361 transport 363 3.2. Message Format 365 The CoAP message format defined in [RFC7252], as shown in Figure 3, 366 relies on the datagram transport (UDP, or DTLS over UDP) for keeping 367 the individual messages separate and for providing length 368 information. 370 0 1 2 3 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |Ver| T | TKL | Code | Message ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Token (if any, TKL bytes) ... 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Options (if any) ... 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |1 1 1 1 1 1 1 1| Payload (if any) ... 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 3: RFC 7252 defined CoAP Message Format 384 The CoAP over TCP message format is very similar to the format 385 specified for CoAP over UDP. The differences are as follows: 387 o Since the underlying TCP connection provides retransmissions and 388 deduplication, there is no need for the reliability mechanisms 389 provided by CoAP over UDP. The Type (T) and Message ID fields in 390 the CoAP message header are elided. 392 o The Version (Vers) field is elided as well. In contrast to the 393 message format of CoAP over UDP, the message format for CoAP over 394 TCP does not include a version number. CoAP is defined in 395 [RFC7252] with a version number of 1. At this time, there is no 396 known reason to support version numbers different from 1. If 397 version negotiation needs to be addressed in the future, then 398 Capabilities and Settings Messages (CSM see Section 5.3) have been 399 specifically designed to enable such a potential feature. 401 o In a stream oriented transport protocol such as TCP, a form of 402 message delimitation is needed. For this purpose, CoAP over TCP 403 introduces a length field with variable size. Figure 4 shows the 404 adjusted CoAP message format with a modified structure for the 405 fixed header (first 4 bytes of the CoAP over UDP header), which 406 includes the length information of variable size. 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Len | TKL | Extended Length (if any, as chosen by Len) ... 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Code | Token (if any, TKL bytes) ... 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Options (if any) ... 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |1 1 1 1 1 1 1 1| Payload (if any) ... 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 4: CoAP frame for reliable transports 422 Length (Len): 4-bit unsigned integer. A value between 0 and 12 423 inclusive indicates the length of the message in bytes starting 424 with the first bit of the Options field. Three values are 425 reserved for special constructs: 427 13: An 8-bit unsigned integer (Extended Length) follows the 428 initial byte and indicates the length of options/payload minus 429 13. 431 14: A 16-bit unsigned integer (Extended Length) in network byte 432 order follows the initial byte and indicates the length of 433 options/payload minus 269. 435 15: A 32-bit unsigned integer (Extended Length) in network byte 436 order follows the initial byte and indicates the length of 437 options/payload minus 65805. 439 The encoding of the Length field is modeled after the Option Length 440 field of the CoAP Options (see Section 3.1 of [RFC7252]). 442 For simplicity, a Payload Marker (0xFF) is shown in Figure 4; the 443 Payload Marker indicates the start of the optional payload and is 444 absent for zero-length payloads (see Section 3 of [RFC7252]). (If 445 present, the Payload Marker is included in the message length, which 446 counts from the start of the Options field to the end of the Payload 447 field.) 449 For example: A CoAP message just containing a 2.03 code with the 450 token 7f and no options or payload is encoded as shown in Figure 5. 452 0 1 2 453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | 0x01 | 0x43 | 0x7f | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Len = 0 ------> 0x01 459 TKL = 1 ___/ 460 Code = 2.03 --> 0x43 461 Token = 0x7f 463 Figure 5: CoAP message with no options or payload 465 The semantics of the other CoAP header fields are left unchanged. 467 3.3. Message Transmission 469 Once a transport connection is established, each endpoint MUST send a 470 Capabilities and Settings message (CSM, see Section 5.3) as their 471 first message on the connection. This message establishes the 472 initial settings and capabilities for the endpoint, such as maximum 473 message size or support for block-wise transfers. The absence of 474 options in the CSM indicates that base values are assumed. 476 To avoid a deadlock, the Connection Initiator MUST NOT wait for the 477 Connection Acceptor to send its initial CSM message before sending 478 its own initial CSM message. Conversely, the Connection Acceptor MAY 479 wait for the Connection Initiator to send its initial CSM message 480 before sending its own initial CSM message. 482 To avoid unnecessary latency, a Connection Initiator MAY send 483 additional messages after its initial CSM without waiting to receive 484 the Connection Acceptor's CSM; however, it is important to note that 485 the Connection Acceptor's CSM might indicate capabilities that impact 486 how the initiator is expected to communicate with the acceptor. For 487 example, the acceptor CSM could indicate a Max-Message-Size option 488 (see Section 5.3.1) that is smaller than the base value (1152) in 489 order to limit both buffering requirements and head-of-line blocking. 491 Endpoints MUST treat a missing or invalid CSM as a connection error 492 and abort the connection (see Section 5.6). 494 CoAP requests and responses are exchanged asynchronously over the 495 transport connection. A CoAP client can send multiple requests 496 without waiting for a response and the CoAP server can return 497 responses in any order. Responses MUST be returned over the same 498 connection as the originating request. Concurrent requests are 499 differentiated by their Token, which is scoped locally to the 500 connection. 502 The transport connection is bi-directional, so requests can be sent 503 both by the entity that established the connection (Connection 504 Initiator) and the remote host (Connection Acceptor). If one side 505 does not implement a CoAP server, an error response MUST be returned 506 for all CoAP requests from the other side. The simplest approach is 507 to always return 5.01 (Not Implemented). A more elaborate mock 508 server could also return 4.xx responses such as 4.04 (Not Found) or 509 4.02 (Bad Option) where appropriate. 511 Retransmission and deduplication of messages is provided by the TCP 512 protocol. 514 3.4. Connection Health 516 Empty messages (Code 0.00) can always be sent and MUST be ignored by 517 the recipient. This provides a basic keep-alive function that can 518 refresh NAT bindings. 520 If a CoAP client does not receive any response for some time after 521 sending a CoAP request (or, similarly, when a client observes a 522 resource and it does not receive any notification for some time), it 523 can send a CoAP Ping Signaling message (see Section 5.4) to test the 524 transport connection and verify that the CoAP server is responsive. 526 When the underlying transport connection is closed or reset, the 527 signaling state and any observation state (see Section 7.4) 528 associated with the connection are removed. In flight messages may 529 or may not be lost. 531 4. CoAP over WebSockets 533 CoAP over WebSockets is intentionally similar to CoAP over TCP; 534 therefore, this section only specifies the differences between the 535 transports. 537 CoAP over WebSockets can be used in a number of configurations. The 538 most basic configuration is a CoAP client retrieving or updating a 539 CoAP resource located on a CoAP server that exposes a WebSocket 540 endpoint (see Figure 6). The CoAP client acts as the WebSocket 541 client, establishes a WebSocket connection, and sends a CoAP request, 542 to which the CoAP server returns a CoAP response. The WebSocket 543 connection can be used for any number of requests. 545 ___________ ___________ 546 | | | | 547 | _|___ requests ___|_ | 548 | CoAP / \ \ -------------> / / \ CoAP | 549 | Client \__/__/ <------------- \__\__/ Server | 550 | | responses | | 551 |___________| |___________| 552 WebSocket =============> WebSocket 553 Client Connection Server 555 Figure 6: CoAP Client (WebSocket client) accesses CoAP Server 556 (WebSocket server) 558 The challenge with this configuration is how to identify a resource 559 in the namespace of the CoAP server. When the WebSocket protocol is 560 used by a dedicated client directly (i.e., not from a web page 561 through a web browser), the client can connect to any WebSocket 562 endpoint. Section 8.3 and Section 8.4 define new URI schemes that 563 enable the client to identify both a WebSocket endpoint and the path 564 and query of the CoAP resource within that endpoint. 566 Another possible configuration is to set up a CoAP forward proxy at 567 the WebSocket endpoint. Depending on what transports are available 568 to the proxy, it could forward the request to a CoAP server with a 569 CoAP UDP endpoint (Figure 7), an SMS endpoint (a.k.a. mobile phone), 570 or even another WebSocket endpoint. The CoAP client specifies the 571 resource to be updated or retrieved in the Proxy-Uri Option. 573 ___________ ___________ ___________ 574 | | | | | | 575 | _|___ ___|_ _|___ ___|_ | 576 | CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP | 577 | Client \__/__/ <--- \__\__/ Proxy \__/__/ <--- \__\__/ Server | 578 | | | | | | 579 |___________| |___________| |___________| 580 WebSocket ===> WebSocket UDP UDP 581 Client Server Client Server 583 Figure 7: CoAP Client (WebSocket client) accesses CoAP Server (UDP 584 server) via a CoAP proxy (WebSocket server/UDP client) 586 A third possible configuration is a CoAP server running inside a web 587 browser (Figure 8). The web browser initially connects to a 588 WebSocket endpoint and is then reachable through the WebSocket 589 server. When no connection exists, the CoAP server is unreachable. 590 Because the WebSocket server is the only way to reach the CoAP 591 server, the CoAP proxy should be a reverse-proxy. 593 ___________ ___________ ___________ 594 | | | | | | 595 | _|___ ___|_ _|___ ___|_ | 596 | CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP | 597 | Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server | 598 | | | | | | 599 |___________| |___________| |___________| 600 UDP UDP WebSocket <=== WebSocket 601 Client Server Server Client 603 Figure 8: CoAP Client (UDP client) accesses CoAP Server (WebSocket 604 client) via a CoAP proxy (UDP server/WebSocket server) 606 Further configurations are possible, including those where a 607 WebSocket connection is established through an HTTP proxy. 609 4.1. Opening Handshake 611 Before CoAP requests and responses are exchanged, a WebSocket 612 connection is established as defined in Section 4 of [RFC6455]. 613 Figure 9 shows an example. 615 The WebSocket client MUST include the subprotocol name "coap" in the 616 list of protocols, which indicates support for the protocol defined 617 in this document. 619 The WebSocket client includes the hostname of the WebSocket server in 620 the Host header field of its handshake as per [RFC6455]. The Host 621 header field also indicates the default value of the Uri-Host Option 622 in requests from the WebSocket client to the WebSocket server. 624 GET /.well-known/coap HTTP/1.1 625 Host: example.org 626 Upgrade: websocket 627 Connection: Upgrade 628 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 629 Sec-WebSocket-Protocol: coap 630 Sec-WebSocket-Version: 13 632 HTTP/1.1 101 Switching Protocols 633 Upgrade: websocket 634 Connection: Upgrade 635 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 636 Sec-WebSocket-Protocol: coap 638 Figure 9: Example of an Opening Handshake 640 4.2. Message Format 642 Once a WebSocket connection is established, CoAP requests and 643 responses can be exchanged as WebSocket messages. Since CoAP uses a 644 binary message format, the messages are transmitted in binary data 645 frames as specified in Sections 5 and 6 of [RFC6455]. 647 The message format shown in Figure 10 is the same as the CoAP over 648 TCP message format (see Section 3.2) with one change. The Length 649 (Len) field MUST be set to zero because the WebSockets frame contains 650 the length. 652 0 1 2 3 653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Len=0 | TKL | Code | Token (TKL bytes) ... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Options (if any) ... 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |1 1 1 1 1 1 1 1| Payload (if any) ... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Figure 10: CoAP Message Format over WebSockets 664 As with CoAP over TCP, the message format for CoAP over WebSockets 665 eliminates the Version field defined in CoAP over UDP. If CoAP 666 version negotiation is required in the future, CoAP over WebSockets 667 can address the requirement by the definition of a new subprotocol 668 identifier that is negotiated during the opening handshake. 670 Requests and response messages can be fragmented as specified in 671 Section 5.4 of [RFC6455], though typically they are sent unfragmented 672 as they tend to be small and fully buffered before transmission. The 673 WebSocket protocol does not provide means for multiplexing. If it is 674 not desirable for a large message to monopolize the connection, 675 requests and responses can be transferred in a block-wise fashion as 676 defined in [RFC7959]. 678 4.3. Message Transmission 680 As with CoAP over TCP, each endpoint MUST send a Capabilities and 681 Settings message (CSM see Section 5.3) as their first message on the 682 WebSocket connection. 684 CoAP requests and responses are exchanged asynchronously over the 685 WebSocket connection. A CoAP client can send multiple requests 686 without waiting for a response and the CoAP server can return 687 responses in any order. Responses MUST be returned over the same 688 connection as the originating request. Concurrent requests are 689 differentiated by their Token, which is scoped locally to the 690 connection. 692 The connection is bi-directional, so requests can be sent both by the 693 entity that established the connection and the remote host. 695 As with CoAP over TCP, retransmission and deduplication of messages 696 is provided by the WebSocket protocol. CoAP over WebSockets 697 therefore does not make a distinction between Confirmable or Non- 698 Confirmable messages, and does not provide Acknowledgement or Reset 699 messages. 701 4.4. Connection Health 703 As with CoAP over TCP, a CoAP client can test the health of the CoAP 704 over WebSocket connection by sending a CoAP Ping Signaling message 705 (Section 5.4). WebSocket Ping and unsolicited Pong frames 706 (Section 5.5 of [RFC6455]) SHOULD NOT be used to ensure that 707 redundant maintenance traffic is not transmitted. 709 5. Signaling 711 Signaling messages are specifically introduced only for CoAP over 712 reliable transports to allow peers to: 714 o Learn related characteristics, such as maximum message size for 715 the connection 717 o Shut down the connection in an orderly fashion 718 o Provide diagnostic information when terminating a connection in 719 response to a serious error condition 721 Signaling is a third basic kind of message in CoAP, after requests 722 and responses. Signaling messages share a common structure with the 723 existing CoAP messages. There is a code, a token, options, and an 724 optional payload. 726 (See Section 3 of [RFC7252] for the overall structure of the message 727 format, option format, and option value format.) 729 5.1. Signaling Codes 731 A code in the 7.00-7.31 range indicates a Signaling message. Values 732 in this range are assigned by the "CoAP Signaling Codes" sub-registry 733 (see Section 11.1). 735 For each message, there is a sender and a peer receiving the message. 737 Payloads in Signaling messages are diagnostic payloads as defined in 738 Section 5.5.2 of [RFC7252]), unless otherwise defined by a Signaling 739 message option. 741 5.2. Signaling Option Numbers 743 Option numbers for Signaling messages are specific to the message 744 code. They do not share the number space with CoAP options for 745 request/response messages or with Signaling messages using other 746 codes. 748 Option numbers are assigned by the "CoAP Signaling Option Numbers" 749 sub-registry (see Section 11.2). 751 Signaling options are elective or critical as defined in 752 Section 5.4.1 of [RFC7252]. If a Signaling option is critical and 753 not understood by the receiver, it MUST abort the connection (see 754 Section 5.6). If the option is understood but cannot be processed, 755 the option documents the behavior. 757 5.3. Capabilities and Settings Messages (CSM) 759 Capabilities and Settings messages (CSM) are used for two purposes: 761 o Each capability option indicates one capability of the sender to 762 the recipient. 764 o Each setting option indicates a setting that will be applied by 765 the sender. 767 One CSM MUST be sent by each endpoint at the start of the transport 768 connection. Further CSM MAY be sent at any other time by either 769 endpoint over the lifetime of the connection. 771 Both capability and setting options are cumulative. A CSM does not 772 invalidate a previously sent capability indication or setting even if 773 it is not repeated. A capability message without any option is a no- 774 operation (and can be used as such). An option that is sent might 775 override a previous value for the same option. The option defines 776 how to handle this case if needed. 778 Base values are listed below for CSM Options. These are the values 779 for the capability and setting before any Capabilities and Settings 780 messages send a modified value. 782 These are not default values for the option, as defined in 783 Section 5.4.4 in [RFC7252]. Default values apply on a per-message 784 basis and thus reset when the value is not present in a given 785 Capabilities and Settings message. 787 Capabilities and Settings messages are indicated by the 7.01 code 788 (CSM). 790 5.3.1. Max-Message-Size Capability Option 792 The sender can use the elective Max-Message-Size Option to indicate 793 the maximum size of a message in bytes that it can receive. The 794 message size indicated includes the entire message, starting from the 795 first byte of the message header and ending at the end of the message 796 payload. 798 (Note that there is no relationship of the message size to the 799 overall request or response body size that may be achievable in 800 block-wise transfer. For example, the exchange depicted further down 801 in Figure 13 can be performed if the CoAP client indicates a value of 802 around 6000 bytes for the Max-Message-Size option, even though the 803 total body size transferred to the client is 3072 + 5120 + 4711 = 804 12903 bytes.) 806 +---+---+---+---------+------------------+--------+--------+--------+ 807 | # | C | R | Applies | Name | Format | Length | Base | 808 | | | | to | | | | Value | 809 +---+---+---+---------+------------------+--------+--------+--------+ 810 | 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 | 811 +---+---+---+---------+------------------+--------+--------+--------+ 813 C=Critical, R=Repeatable 815 As per Section 4.6 of [RFC7252], the base value (and the value used 816 when this option is not implemented) is 1152. 818 The active value of the Max-Message-Size Option is replaced each time 819 the option is sent with a modified value. Its starting value is its 820 base value. 822 5.3.2. Block-Wise-Transfer Capability Option 824 +---+---+---+---------+------------------+--------+--------+--------+ 825 | # | C | R | Applies | Name | Format | Length | Base | 826 | | | | to | | | | Value | 827 +---+---+---+---------+------------------+--------+--------+--------+ 828 | 4 | | | CSM | Block-Wise- | empty | 0 | (none) | 829 | | | | | Transfer | | | | 830 +---+---+---+---------+------------------+--------+--------+--------+ 832 C=Critical, R=Repeatable 834 A sender can use the elective Block-Wise-Transfer Option to indicate 835 that it supports the block-wise transfer protocol [RFC7959]. 837 If the option is not given, the peer has no information about whether 838 block-wise transfers are supported by the sender or not. An 839 implementation wishing to offer block-wise transfers to its peer 840 therefore needs to indicate the Block-Wise-Transfer Option. 842 If a Max-Message-Size Option is indicated with a value that is 843 greater than 1152 (in the same or a different CSM message), the 844 Block-Wise-Transfer Option also indicates support for BERT (see 845 Section 6). Subsequently, if the Max-Message-Size Option is 846 indicated with a value equal to or less than 1152, BERT support is no 847 longer indicated. (Note that indication of BERT support obliges 848 neither peer to actually choose to make use of BERT.) 850 Implementation note: When indicating a value of the Max-Message-Size 851 option with an intention to enable BERT, the indicating 852 implementation may want to choose a BERT size message it wants to 853 encourage and add a delta for the header and any options that also 854 need to be included in the message. Section 4.6 of [RFC7252] adds 855 128 bytes to a maximum block size of 1024 to arrive at a default 856 message size of 1152. A BERT-enabled implementation may want to 857 indicate a BERT block size of 2048 or a higher multiple of 1024, and 858 at the same time be more generous for the size of header and options 859 added (say, 256 or 512). Adding 1024 or more however to the base 860 BERT block size may encourage the peer implementation to vary the 861 BERT block size based on the size of the options included, which can 862 be harder to establish interoperability for. 864 5.4. Ping and Pong Messages 866 In CoAP over reliable transports, Empty messages (Code 0.00) can 867 always be sent and MUST be ignored by the recipient. This provides a 868 basic keep-alive function. In contrast, Ping and Pong messages are a 869 bidirectional exchange. 871 Upon receipt of a Ping message, the receiver MUST return a Pong 872 message with an identical token in response. Unless the Ping carries 873 an option with delaying semantics such as the Custody Option, it 874 SHOULD respond as soon as practical. As with all Signaling messages, 875 the recipient of a Ping or Pong message MUST ignore elective options 876 it does not understand. 878 Ping and Pong messages are indicated by the 7.02 code (Ping) and the 879 7.03 code (Pong). 881 Note that, as with similar mechanisms defined in [RFC6455] and 882 [RFC7540], the present specification does not define any specific 883 maximum time that the sender of a Ping message has to allow waiting 884 for a Pong reply. Any limitations on the patience for this reply are 885 a matter of the application making use of these messages, as is any 886 approach to recover from a failure to respond in time. 888 5.4.1. Custody Option 890 +---+---+---+----------+----------------+--------+--------+---------+ 891 | # | C | R | Applies | Name | Format | Length | Base | 892 | | | | to | | | | Value | 893 +---+---+---+----------+----------------+--------+--------+---------+ 894 | 2 | | | Ping, | Custody | empty | 0 | (none) | 895 | | | | Pong | | | | | 896 +---+---+---+----------+----------------+--------+--------+---------+ 898 C=Critical, R=Repeatable 900 When responding to a Ping message, the receiver can include an 901 elective Custody Option in the Pong message. This option indicates 902 that the application has processed all the request/response messages 903 received prior to the Ping message on the current connection. (Note 904 that there is no definition of specific application semantics for 905 "processed", but there is an expectation that the receiver of a Pong 906 Message with a Custody Option should be able to free buffers based on 907 this indication.) 909 A sender can also include an elective Custody Option in a Ping 910 message to explicitly request the inclusion of an elective Custody 911 Option in the corresponding Pong message. In that case, the receiver 912 SHOULD delay its Pong message until it finishes processing all the 913 request/response messages received prior to the Ping message on the 914 current connection. 916 5.5. Release Messages 918 A Release message indicates that the sender does not want to continue 919 maintaining the transport connection and opts for an orderly 920 shutdown, but wants to leave it to the peer to actually start closing 921 the connection. The details are in the options. A diagnostic 922 payload (see Section 5.5.2 of [RFC7252]) MAY be included. 924 A peer will normally respond to a Release message by closing the 925 transport connection. (In case that does not happen, the sender of 926 the release may want to implement a timeout mechanism if getting rid 927 of the connection is actually important to it.) 929 Messages may be in flight or responses outstanding when the sender 930 decides to send a Release message (which is one reason the sender had 931 decided to wait with closing the connection). The peer responding to 932 the Release message SHOULD delay the closing of the connection until 933 it has responded to all requests received by it before the Release 934 message. It also MAY wait for the responses to its own requests. 936 It is NOT RECOMMENDED for the sender of a Release message to continue 937 sending requests on the connection it already indicated to be 938 released: the peer might close the connection at any time and miss 939 those requests. There is no obligation for the peer to check for 940 this condition, though. 942 Release messages are indicated by the 7.04 code (Release). 944 Release messages can indicate one or more reasons using elective 945 options. The following options are defined: 947 +---+---+---+---------+------------------+--------+--------+--------+ 948 | # | C | R | Applies | Name | Format | Length | Base | 949 | | | | to | | | | Value | 950 +---+---+---+---------+------------------+--------+--------+--------+ 951 | 2 | | x | Release | Alternative- | string | 1-255 | (none) | 952 | | | | | Address | | | | 953 +---+---+---+---------+------------------+--------+--------+--------+ 955 C=Critical, R=Repeatable 957 The elective Alternative-Address Option requests the peer to instead 958 open a connection of the same scheme as the present connection to the 959 alternative transport address given. Its value is in the form 960 "authority" as defined in Section 3.2 of [RFC3986]. (Existing state 961 related to the connection is not transferred from the present 962 connection to the new connection.) 964 The Alternative-Address Option is a repeatable option as defined in 965 Section 5.4.5 of [RFC7252]. When multiple occurrences of the option 966 are included, the peer can choose any of the alternative transport 967 addresses. 969 +---+---+---+---------+-----------------+--------+--------+---------+ 970 | # | C | R | Applies | Name | Format | Length | Base | 971 | | | | to | | | | Value | 972 +---+---+---+---------+-----------------+--------+--------+---------+ 973 | 4 | | | Release | Hold-Off | uint | 0-3 | (none) | 974 +---+---+---+---------+-----------------+--------+--------+---------+ 976 C=Critical, R=Repeatable 978 The elective Hold-Off Option indicates that the server is requesting 979 that the peer not reconnect to it for the number of seconds given in 980 the value. 982 5.6. Abort Messages 984 An Abort message indicates that the sender is unable to continue 985 maintaining the transport connection and cannot even wait for an 986 orderly release. The sender shuts down the connection immediately 987 after the abort (and may or may not wait for a Release or Abort 988 message or connection shutdown in the inverse direction). A 989 diagnostic payload (see Section 5.5.2 of [RFC7252]) SHOULD be 990 included in the Abort message. Messages may be in flight or 991 responses outstanding when the sender decides to send an Abort 992 message. The general expectation is that these will NOT be 993 processed. 995 Abort messages are indicated by the 7.05 code (Abort). 997 Abort messages can indicate one or more reasons using elective 998 options. The following option is defined: 1000 +---+---+---+---------+-----------------+--------+--------+---------+ 1001 | # | C | R | Applies | Name | Format | Length | Base | 1002 | | | | to | | | | Value | 1003 +---+---+---+---------+-----------------+--------+--------+---------+ 1004 | 2 | | | Abort | Bad-CSM-Option | uint | 0-2 | (none) | 1005 +---+---+---+---------+-----------------+--------+--------+---------+ 1007 C=Critical, R=Repeatable 1009 The elective Bad-CSM-Option Option indicates that the sender is 1010 unable to process the CSM option identified by its option number, 1011 e.g. when it is critical and the option number is unknown by the 1012 sender, or when there is parameter problem with the value of an 1013 elective option. More detailed information SHOULD be included as a 1014 diagnostic payload. 1016 For CoAP over UDP, messages which contain syntax violations are 1017 processed as message format errors. As described in Sections 4.2 and 1018 4.3 of [RFC7252], such messages are rejected by sending a matching 1019 Reset message and otherwise ignoring the message. 1021 For CoAP over reliable transports, the recipient rejects such 1022 messages by sending an Abort message and otherwise ignoring (not 1023 processing) the message. No specific option has been defined for the 1024 Abort message in this case, as the details are best left to a 1025 diagnostic payload. 1027 5.7. Signaling examples 1029 An encoded example of a Ping message with a non-empty token is shown 1030 in Figure 11. 1032 0 1 2 1033 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | 0x01 | 0xe2 | 0x42 | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Len = 0 -------> 0x01 1039 TKL = 1 ___/ 1040 Code = 7.02 Ping --> 0xe2 1041 Token = 0x42 1043 Figure 11: Ping Message Example 1045 An encoded example of the corresponding Pong message is shown in 1046 Figure 12. 1048 0 1 2 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | 0x01 | 0xe3 | 0x42 | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Len = 0 -------> 0x01 1055 TKL = 1 ___/ 1056 Code = 7.03 Pong --> 0xe3 1057 Token = 0x42 1059 Figure 12: Pong Message Example 1061 6. Block-wise Transfer and Reliable Transports 1063 The message size restrictions defined in Section 4.6 of CoAP 1064 [RFC7252] to avoid IP fragmentation are not necessary when CoAP is 1065 used over a reliable transport. While this suggests that the Block- 1066 wise transfer protocol [RFC7959] is also no longer needed, it remains 1067 applicable for a number of cases: 1069 o large messages, such as firmware downloads, may cause undesired 1070 head-of-line blocking when a single transport connection is used 1072 o a UDP-to-TCP gateway may simply not have the context to convert a 1073 message with a Block Option into the equivalent exchange without 1074 any use of a Block Option (it would need to convert the entire 1075 blockwise exchange from start to end into a single exchange) 1077 The 'Block-wise Extension for Reliable Transport (BERT)' extends the 1078 Block protocol to enable the use of larger messages over a reliable 1079 transport. 1081 The use of this new extension is signaled by sending Block1 or Block2 1082 Options with SZX == 7 (a "BERT option"). SZX == 7 is a reserved 1083 value in [RFC7959]. 1085 In control usage, a BERT option is interpreted in the same way as the 1086 equivalent Option with SZX == 6, except that it also indicates the 1087 capability to process BERT blocks. As with the basic Block protocol, 1088 the recipient of a CoAP request with a BERT option in control usage 1089 is allowed to respond with a different SZX value, e.g. to send a non- 1090 BERT block instead. 1092 In descriptive usage, a BERT Option is interpreted in the same way as 1093 the equivalent Option with SZX == 6, except that the payload is also 1094 allowed to contain multiple blocks. For non-final BERT blocks, the 1095 payload is always a multiple of 1024 bytes. For final BERT blocks, 1096 the payload is a multiple (possibly 0) of 1024 bytes plus a partial 1097 block of less than 1024 bytes. 1099 The recipient of a non-final BERT block (M=1) conceptually partitions 1100 the payload into a sequence of 1024-byte blocks and acts exactly as 1101 if it had received this sequence in conjunction with block numbers 1102 starting at, and sequentially increasing from, the block number given 1103 in the Block Option. In other words, the entire BERT block is 1104 positioned at the byte position that results from multiplying the 1105 block number with 1024. The position of further blocks to be 1106 transferred is indicated by incrementing the block number by the 1107 number of elements in this sequence (i.e., the size of the payload 1108 divided by 1024 bytes). 1110 As with SZX == 6, the recipient of a final BERT block (M=0) simply 1111 appends the payload at the byte position that is indicated by the 1112 block number multiplied with 1024. 1114 The following examples illustrate BERT options. A value of SZX == 7 1115 is labeled as "BERT" or as "BERT(nnn)" to indicate a payload of size 1116 nnn. 1118 In all these examples, a Block Option is decomposed to indicate the 1119 kind of Block Option (1 or 2) followed by a colon, the block number 1120 (NUM), more bit (M), and block size (2**(SZX+4)) separated by 1121 slashes. E.g., a Block2 Option value of 33 would be shown as 1122 2:2/0/32), or a Block1 Option value of 59 would be shown as 1123 1:3/1/128. 1125 6.1. Example: GET with BERT Blocks 1127 Figure 13 shows a GET request with a response that is split into 1128 three BERT blocks. The first response contains 3072 bytes of 1129 payload; the second, 5120; and the third, 4711. Note how the block 1130 number increments to move the position inside the response body 1131 forward. 1133 CoAP Client CoAP Server 1134 | | 1135 | GET, /status ------> | 1136 | | 1137 | <------ 2.05 Content, 2:0/1/BERT(3072) | 1138 | | 1139 | GET, /status, 2:3/0/BERT ------> | 1140 | | 1141 | <------ 2.05 Content, 2:3/1/BERT(5120) | 1142 | | 1143 | GET, /status, 2:8/0/BERT ------> | 1144 | | 1145 | <------ 2.05 Content, 2:8/0/BERT(4711) | 1147 Figure 13: GET with BERT blocks 1149 6.2. Example: PUT with BERT Blocks 1151 Figure 14 demonstrates a PUT exchange with BERT blocks. 1153 CoAP Client CoAP Server 1154 | | 1155 | PUT, /options, 1:0/1/BERT(8192) ------> | 1156 | | 1157 | <------ 2.31 Continue, 1:0/1/BERT | 1158 | | 1159 | PUT, /options, 1:8/1/BERT(16384) ------> | 1160 | | 1161 | <------ 2.31 Continue, 1:8/1/BERT | 1162 | | 1163 | PUT, /options, 1:24/0/BERT(5683) ------> | 1164 | | 1165 | <------ 2.04 Changed, 1:24/0/BERT | 1166 | | 1168 Figure 14: PUT with BERT blocks 1170 7. Observing Resources over Reliable Transports 1172 This section describes how the procedures defined in [RFC7641] for 1173 observing resources over CoAP are applied (and modified, as needed) 1174 for reliable transports. In this section, "client" and "server" 1175 refer to the CoAP client and CoAP server. 1177 7.1. Notifications and Reordering 1179 When using the Observe Option with CoAP over UDP, notifications from 1180 the server set the option value to an increasing sequence number for 1181 reordering detection on the client since messages can arrive in a 1182 different order than they were sent. This sequence number is not 1183 required for CoAP over reliable transports since the TCP protocol 1184 ensures reliable and ordered delivery of messages. The value of the 1185 Observe Option in 2.xx notifications MAY be empty on transmission and 1186 MUST be ignored on reception. 1188 Implementation note: This means that a proxy from a reordering 1189 transport to a reliable (in-order) transport (such as a UDP-to-TCP 1190 proxy) needs to process the Observe Option in notifications according 1191 to the rules in Section 3.4 of [RFC7641]. 1193 7.2. Transmission and Acknowledgements 1195 For CoAP over UDP, server notifications to the client can be 1196 confirmable or non-confirmable. A confirmable message requires the 1197 client to either respond with an acknowledgement message or a reset 1198 message. An acknowledgement message indicates that the client is 1199 alive and wishes to receive further notifications. A reset message 1200 indicates that the client does not recognize the token which causes 1201 the server to remove the associated entry from the list of observers. 1203 Since TCP eliminates the need for the message layer to support 1204 reliability, CoAP over reliable transports does not support 1205 confirmable or non-confirmable message types. All notifications are 1206 delivered reliably to the client with positive acknowledgement of 1207 receipt occurring at the TCP level. If the client does not recognize 1208 the token in a notification, it MAY immediately abort the connection 1209 (see Section 5.6). 1211 7.3. Freshness 1213 For CoAP over UDP, if a client does not receive a notification for 1214 some time, it MAY send a new GET request with the same token as the 1215 original request to re-register its interest in a resource and verify 1216 that the server is still responsive. For CoAP over reliable 1217 transports, it is more efficient to check the health of the 1218 connection (and all its active observations) by sending a single CoAP 1219 Ping Signaling message (Section 5.4) rather than individual requests 1220 to confirm each active observation. (Note that such a Ping/Pong only 1221 confirms a single hop: there is no obligation, and no expectation, of 1222 a proxy to react to a Ping by checking all its onward observations or 1223 all the connections, if any, underlying them. A proxy MAY maintain 1224 its own schedule for confirming the onward observations it relies on; 1225 it is however generally inadvisable for a proxy to generate a large 1226 number of outgoing checks based on a single incoming check.) 1228 7.4. Cancellation 1230 For CoAP over UDP, a client that is no longer interested in receiving 1231 notifications can "forget" the observation and respond to the next 1232 notification from the server with a reset message to cancel the 1233 observation. 1235 For CoAP over reliable transports, a client MUST explicitly 1236 deregister by issuing a GET request that has the Token field set to 1237 the token of the observation to be cancelled and includes an Observe 1238 Option with the value set to 1 (deregister). 1240 If the client observes one or more resources over a reliable 1241 transport, then the CoAP server (or intermediary in the role of the 1242 CoAP server) MUST remove all entries associated with the client 1243 endpoint from the lists of observers when the connection is either 1244 closed or times out. 1246 8. CoAP over Reliable Transport URIs 1248 CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes. 1249 This document introduces four additional URI schemes for identifying 1250 CoAP resources and providing a means of locating the resource: 1252 o the "coap+tcp" URI scheme for CoAP over TCP 1254 o the "coaps+tcp" URI scheme for CoAP over TCP secured by TLS 1256 o the "coap+ws" URI scheme for CoAP over WebSockets 1258 o the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS 1260 Resources made available via these schemes have no shared identity 1261 even if their resource identifiers indicate the same authority (the 1262 same host listening to the same TCP port). They are hosted in 1263 distinct namespaces because each URI scheme implies a distinct origin 1264 server. 1266 The syntax for the URI schemes in this section are specified using 1267 Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of 1268 "host", "port", "path-abempty", and "query" are adopted from 1269 [RFC3986]. 1271 Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these 1272 schemes. 1274 As with the "coap" and "coaps" schemes defined in [RFC7252], all URI 1275 schemes defined in this section also support the path prefix "/.well- 1276 known/" defined by [RFC5785] for "well-known locations" in the 1277 namespace of a host. This enables discovery as per Section 7 of 1278 [RFC7252]. 1280 8.1. coap+tcp URI scheme 1282 The "coap+tcp" URI scheme identifies CoAP resources that are intended 1283 to be accessible using CoAP over TCP. 1285 coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] 1286 path-abempty [ "?" query ] 1288 The syntax defined in Section 6.1 of [RFC7252] applies to this URI 1289 scheme with the following changes: 1291 o The port subcomponent indicates the TCP port at which the CoAP 1292 Connection Acceptor is located. (If it is empty or not given, 1293 then the default port 5683 is assumed, as with UDP.) 1295 Encoding considerations: The scheme encoding conforms to the 1296 encoding rules established for URIs in [RFC3986]. 1298 Interoperability considerations: None. 1300 Security considerations: See Section 11.1 of [RFC7252]. 1302 8.2. coaps+tcp URI scheme 1304 The "coaps+tcp" URI scheme identifies CoAP resources that are 1305 intended to be accessible using CoAP over TCP secured with TLS. 1307 coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] 1308 path-abempty [ "?" query ] 1310 The syntax defined in Section 6.2 of [RFC7252] applies to this URI 1311 scheme, with the following changes: 1313 o The port subcomponent indicates the TCP port at which the TLS 1314 server for the CoAP Connection Acceptor is located. If it is 1315 empty or not given, then the default port 5684 is assumed. 1317 o If a TLS server does not support the Application-Layer Protocol 1318 Negotiation Extension (ALPN) [RFC7301] or wishes to accommodate 1319 TLS clients that do not support ALPN, it MAY offer a coaps+tcp 1320 endpoint on TCP port 5684. This endpoint MAY also be ALPN 1321 enabled. A TLS server MAY offer coaps+tcp endpoints on ports 1322 other than TCP port 5684, which MUST be ALPN enabled. 1324 o For TCP ports other than port 5684, the TLS client MUST use the 1325 ALPN extension to advertise the "coap" protocol identifier (see 1326 Section 11.7) in the list of protocols in its ClientHello. If the 1327 TCP server selects and returns the "coap" protocol identifier 1328 using the ALPN extension in its ServerHello, then the connection 1329 succeeds. If the TLS server either does not negotiate the ALPN 1330 extension or returns a no_application_protocol alert, the TLS 1331 client MUST close the connection. 1333 o For TCP port 5684, a TLS client MAY use the ALPN extension to 1334 advertise the "coap" protocol identifier in the list of protocols 1335 in its ClientHello. If the TLS server selects and returns the 1336 "coap" protocol identifier using the ALPN extension in its 1337 ServerHello, then the connection succeeds. If the TLS server 1338 returns a no_application_protocol alert, then the TLS client MUST 1339 close the connection. If the TLS server does not negotiate the 1340 ALPN extension, then coaps+tcp is implicitly selected. 1342 o For TCP port 5684, if the TLS client does not use the ALPN 1343 extension to negotiate the protocol, then coaps+tcp is implicitly 1344 selected. 1346 Encoding considerations: The scheme encoding conforms to the 1347 encoding rules established for URIs in [RFC3986]. 1349 Interoperability considerations: None. 1351 Security considerations: See Section 11.1 of [RFC7252]. 1353 8.3. coap+ws URI scheme 1355 The "coap+ws" URI scheme identifies CoAP resources that are intended 1356 to be accessible using CoAP over WebSockets. 1358 coap-ws-URI = "coap+ws:" "//" host [ ":" port ] 1359 path-abempty [ "?" query ] 1361 The port subcomponent is OPTIONAL. The default is port 80. 1363 The WebSocket endpoint is identified by a "ws" URI that is composed 1364 of the authority part of the "coap+ws" URI and the well-known path 1365 "/.well-known/coap" [RFC5785] [I-D.bormann-hybi-ws-wk]. The path and 1366 query parts of a "coap+ws" URI identify a resource within the 1367 specified endpoint which can be operated on by the methods defined by 1368 CoAP: 1370 coap+ws://example.org/sensors/temperature?u=Cel 1371 \______ ______/\___________ ___________/ 1372 \/ \/ 1373 Uri-Path: "sensors" 1374 ws://example.org/.well-known/coap Uri-Path: "temperature" 1375 Uri-Query: "u=Cel" 1377 Figure 15: The "coap+ws" URI Scheme 1379 Encoding considerations: The scheme encoding conforms to the 1380 encoding rules established for URIs in [RFC3986]. 1382 Interoperability considerations: None. 1384 Security considerations: See Section 11.1 of [RFC7252]. 1386 8.4. coaps+ws URI scheme 1388 The "coaps+ws" URI scheme identifies CoAP resources that are intended 1389 to be accessible using CoAP over WebSockets secured by TLS. 1391 coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ] 1392 path-abempty [ "?" query ] 1394 The port subcomponent is OPTIONAL. The default is port 443. 1396 The WebSocket endpoint is identified by a "wss" URI that is composed 1397 of the authority part of the "coaps+ws" URI and the well-known path 1398 "/.well-known/coap" [RFC5785] [I-D.bormann-hybi-ws-wk]. The path and 1399 query parts of a "coaps+ws" URI identify a resource within the 1400 specified endpoint which can be operated on by the methods defined by 1401 CoAP. 1403 coaps+ws://example.org/sensors/temperature?u=Cel 1404 \______ ______/\___________ ___________/ 1405 \/ \/ 1406 Uri-Path: "sensors" 1407 wss://example.org/.well-known/coap Uri-Path: "temperature" 1408 Uri-Query: "u=Cel" 1410 Figure 16: The "coaps+ws" URI Scheme 1412 Encoding considerations: The scheme encoding conforms to the 1413 encoding rules established for URIs in [RFC3986]. 1415 Interoperability considerations: None. 1417 Security considerations: See Section 11.1 of [RFC7252]. 1419 8.5. Uri-Host and Uri-Port Options 1421 CoAP over reliable transports maintains the property from 1422 Section 5.10.1 of [RFC7252]: 1424 The default values for the Uri-Host and Uri-Port Options are 1425 sufficient for requests to most servers. 1427 Unless otherwise noted, the default value of the Uri-Host Option is 1428 the IP literal representing the destination IP address of the request 1429 message. The default value of the Uri-Port Option is the destination 1430 TCP port. 1432 For CoAP over TLS, these default values are the same unless Server 1433 Name Indication (SNI) [RFC6066] is negotiated. In this case, the 1434 default value of the Uri-Host Option in requests from the TLS client 1435 to the TLS server is the SNI host. 1437 For CoAP over WebSockets, the default value of the Uri-Host Option in 1438 requests from the WebSocket client to the WebSocket server is 1439 indicated by the Host header field from the WebSocket handshake. 1441 8.6. Decomposing URIs into Options 1443 The steps are the same as specified in Section 6.4 of [RFC7252] with 1444 minor changes. 1446 This step from [RFC7252]: 1448 3. If |url| does not have a component whose value, when 1449 converted to ASCII lowercase, is "coap" or "coaps", then fail 1450 this algorithm. 1452 is updated to: 1454 3. If |url| does not have a component whose value, when 1455 converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", 1456 "coap+ws", or "coaps+ws", then fail this algorithm. 1458 This step from [RFC7252]: 1460 7. If |port| does not equal the request's destination UDP port, 1461 include a Uri-Port Option and let that option's value be |port|. 1463 is updated to: 1465 7. If |port| does not equal the request's destination TCP port, 1466 include a Uri-Port Option and let that option's value be |port|. 1468 8.7. Composing URIs from Options 1470 The steps are the same as specified in Section 6.5 of [RFC7252] with 1471 minor changes. 1473 This step from [RFC7252]: 1475 1. If the request is secured using DTLS, let |url| be the string 1476 "coaps://". Otherwise, let |url| be the string "coap://". 1478 is updated to: 1480 1. For CoAP over TCP, if the request is secured using TLS, let |url| 1481 be the string "coaps+tcp://". Otherwise, let |url| be the string 1482 "coap+tcp://". For CoAP over WebSockets, if the request is 1483 secured using TLS, let |url| be the string "coaps+ws://". 1484 Otherwise, let |url| be the string "coap+ws://". 1486 This step from [RFC7252]: 1488 4. If the request includes a Uri-Port Option, let |port| be that 1489 option's value. Otherwise, let |port| be the request's 1490 destination UDP port. 1492 is updated to: 1494 4. If the request includes a Uri-Port Option, let |port| be that 1495 option's value. Otherwise, let |port| be the request's 1496 destination TCP port. 1498 9. Securing CoAP 1500 Security Challenges for the Internet of Things [SecurityChallenges] 1501 recommends: 1503 ... it is essential that IoT protocol suites specify a mandatory 1504 to implement but optional to use security solution. This will 1505 ensure security is available in all implementations, but 1506 configurable to use when not necessary (e.g., in closed 1507 environment). ... even if those features stretch the capabilities 1508 of such devices. 1510 A security solution MUST be implemented to protect CoAP over reliable 1511 transports and MUST be enabled by default. This document defines the 1512 TLS binding, but alternative solutions at different layers in the 1513 protocol stack MAY be used to protect CoAP over reliable transports 1514 when appropriate. Note that there is ongoing work to support a data 1515 object-based security model for CoAP that is independent of transport 1516 (see [I-D.ietf-core-object-security]). 1518 9.1. TLS binding for CoAP over TCP 1520 The TLS usage guidance in [RFC7925] applies, including the guidance 1521 about cipher suites in that document that are derived from the 1522 mandatory-to-implement (MTI) cipher suites defined in [RFC7252]. 1524 This guidance assumes implementation in a constrained device or for 1525 communication with a constrained device. CoAP over TCP/TLS has, 1526 however, a wider applicability. It may, for example, be implemented 1527 on a gateway or on a device that is less constrained (such as a smart 1528 phone or a tablet), for communication with a peer that is likewise 1529 less constrained, or within a backend environment that only 1530 communicates with constrained devices via proxies. As an exception 1531 to the previous paragraph, in this case, the recommendations in 1532 [RFC7525] are more appropriate. 1534 Since the guidance offered in [RFC7925] and [RFC7525] differs in 1535 terms of algorithms and credential types, it is assumed that a CoAP 1536 over TCP/TLS implementation that needs to support both cases 1537 implements the recommendations offered by both specifications. 1539 During the provisioning phase, a CoAP device is provided with the 1540 security information that it needs, including keying materials, 1541 access control lists, and authorization servers. At the end of the 1542 provisioning phase, the device will be in one of four security modes: 1544 NoSec: TLS is disabled. 1546 PreSharedKey: TLS is enabled. The guidance in Section 4.2 of 1547 [RFC7925] applies. 1549 RawPublicKey: TLS is enabled. The guidance in Section 4.3 of 1550 [RFC7925] applies. 1552 Certificate: TLS is enabled. The guidance in Section 4.4 of 1553 [RFC7925] applies. 1555 The "NoSec" mode is optional-to-implement. The system simply sends 1556 the packets over normal TCP which is indicated by the "coap+tcp" 1557 scheme and the TCP CoAP default port. The system is secured only by 1558 keeping attackers from being able to send or receive packets from the 1559 network with the CoAP nodes. 1561 "PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to- 1562 implement for the TLS binding depending on the credential type used 1563 with the device. These security modes are achieved using TLS and are 1564 indicated by the "coaps+tcp" scheme and TLS-secured CoAP default 1565 port. 1567 9.2. TLS usage for CoAP over WebSockets 1569 A CoAP client requesting a resource identified by a "coaps+ws" URI 1570 negotiates a secure WebSocket connection to a WebSocket server 1571 endpoint with a "wss" URI. This is described in Section 8.4. 1573 The client MUST perform a TLS handshake after opening the connection 1574 to the server. The guidance in Section 4.1 of [RFC6455] applies. 1575 When a CoAP server exposes resources identified by a "coaps+ws" URI, 1576 the guidance in Section 4.4 of [RFC7925] applies towards mandatory- 1577 to-implement TLS functionality for certificates. For the server-side 1578 requirements in accepting incoming connections over a HTTPS (HTTP- 1579 over-TLS) port, the guidance in Section 4.2 of [RFC6455] applies. 1581 Note that this formally inherits the mandatory-to-implement cipher 1582 suites defined in [RFC5246]. However, usually modern browsers 1583 implement more recent cipher suites that then are automatically 1584 picked up via the JavaScript WebSocket API. WebSocket Servers that 1585 provide Secure CoAP over WebSockets for the browser use case will 1586 need to follow the browser preferences and MUST follow [RFC7525]. 1588 10. Security Considerations 1590 The security considerations of [RFC7252] apply. For CoAP over 1591 WebSockets and CoAP over TLS-secured WebSockets, the security 1592 considerations of [RFC6455] also apply. 1594 10.1. Signaling Messages 1596 The guidance given by an Alternative-Address Option cannot be 1597 followed blindly. In particular, a peer MUST NOT assume that a 1598 successful connection to the Alternative-Address inherits all the 1599 security properties of the current connection. 1601 11. IANA Considerations 1603 11.1. Signaling Codes 1605 IANA is requested to create a third sub-registry for values of the 1606 Code field in the CoAP header (Section 12.1 of [RFC7252]). The name 1607 of this sub-registry is "CoAP Signaling Codes". 1609 Each entry in the sub-registry must include the Signaling Code in the 1610 range 7.00-7.31, its name, and a reference to its documentation. 1612 Initial entries in this sub-registry are as follows: 1614 +------+---------+-----------+ 1615 | Code | Name | Reference | 1616 +------+---------+-----------+ 1617 | 7.01 | CSM | [RFCthis] | 1618 | | | | 1619 | 7.02 | Ping | [RFCthis] | 1620 | | | | 1621 | 7.03 | Pong | [RFCthis] | 1622 | | | | 1623 | 7.04 | Release | [RFCthis] | 1624 | | | | 1625 | 7.05 | Abort | [RFCthis] | 1626 +------+---------+-----------+ 1628 Table 1: CoAP Signal Codes 1630 All other Signaling Codes are Unassigned. 1632 The IANA policy for future additions to this sub-registry is "IETF 1633 Review or IESG Approval" as described in [RFC8126]. 1635 11.2. CoAP Signaling Option Numbers Registry 1637 IANA is requested to create a sub-registry for Options Numbers used 1638 in CoAP signaling options within the "CoRE Parameters" registry. The 1639 name of this sub-registry is "CoAP Signaling Option Numbers". 1641 Each entry in the sub-registry must include one or more of the codes 1642 in the Signaling Codes subregistry (Section 11.1), the option number, 1643 the name of the option, and a reference to the option's 1644 documentation. 1646 Initial entries in this sub-registry are as follows: 1648 +------------+--------+---------------------+-----------+ 1649 | Applies to | Number | Name | Reference | 1650 +------------+--------+---------------------+-----------+ 1651 | 7.01 | 2 | Max-Message-Size | [RFCthis] | 1652 | | | | | 1653 | 7.01 | 4 | Block-Wise-Transfer | [RFCthis] | 1654 | | | | | 1655 | 7.02, 7.03 | 2 | Custody | [RFCthis] | 1656 | | | | | 1657 | 7.04 | 2 | Alternative-Address | [RFCthis] | 1658 | | | | | 1659 | 7.04 | 4 | Hold-Off | [RFCthis] | 1660 | | | | | 1661 | 7.05 | 2 | Bad-CSM-Option | [RFCthis] | 1662 +------------+--------+---------------------+-----------+ 1664 Table 2: CoAP Signal Option Codes 1666 The IANA policy for future additions to this sub-registry is based on 1667 number ranges for the option numbers, analogous to the policy defined 1668 in Section 12.2 of [RFC7252]. (The policy is analogous rather than 1669 identical because the structure of the subregistry includes an 1670 additional column; however, the value of this column has no influence 1671 on the policy.) 1673 The documentation for a Signaling Option Number should specify the 1674 semantics of an option with that number, including the following 1675 properties: 1677 o Whether the option is critical or elective, as determined by the 1678 Option Number. 1680 o Whether the option is repeatable. 1682 o The format and length of the option's value. 1684 o The base value for the option, if any. 1686 11.3. Service Name and Port Number Registration 1688 IANA is requested to assign the port number 5683 and the service name 1689 "coap+tcp", in accordance with [RFC6335]. 1691 Service Name. 1692 coap+tcp 1694 Transport Protocol. 1695 tcp 1697 Assignee. 1698 IESG 1700 Contact. 1701 IETF Chair 1703 Description. 1704 Constrained Application Protocol (CoAP) 1706 Reference. 1707 [RFCthis] 1709 Port Number. 1710 5683 1712 11.4. Secure Service Name and Port Number Registration 1714 IANA is requested to assign the port number 5684 and the service name 1715 "coaps+tcp", in accordance with [RFC6335]. The port number is 1716 requested to address the exceptional case of TLS implementations that 1717 do not support the "Application-Layer Protocol Negotiation Extension" 1718 [RFC7301]. 1720 Service Name. 1721 coaps+tcp 1723 Transport Protocol. 1724 tcp 1726 Assignee. 1727 IESG 1729 Contact. 1730 IETF Chair 1732 Description. 1733 Constrained Application Protocol (CoAP) 1735 Reference. 1736 [RFC7301], [RFCthis] 1738 Port Number. 1739 5684 1741 11.5. URI Scheme Registration 1743 URI schemes are registered within the "Uniform Resource Identifier 1744 (URI) Schemes" registry maintained at [IANA.uri-schemes]. 1746 11.5.1. coap+tcp 1748 IANA is requested to register the Uniform Resource Identifier (URI) 1749 scheme "coap+tcp". This registration request complies with 1750 [RFC7595]. 1752 Scheme name: 1753 coap+tcp 1755 Status: 1756 Permanent 1758 Applications/protocols that use this scheme name: 1759 The scheme is used by CoAP endpoints to access CoAP resources 1760 using TCP. 1762 Contact: 1763 IETF chair 1765 Change controller: 1766 IESG 1768 Reference: 1769 Section 8.1 in [RFCthis] 1771 11.5.2. coaps+tcp 1773 IANA is requested to register the Uniform Resource Identifier (URI) 1774 scheme "coaps+tcp". This registration request complies with 1775 [RFC7595]. 1777 Scheme name: 1778 coaps+tcp 1780 Status: 1781 Permanent 1783 Applications/protocols that use this scheme name: 1784 The scheme is used by CoAP endpoints to access CoAP resources 1785 using TLS. 1787 Contact: 1788 IETF chair 1790 Change controller: 1791 IESG 1793 Reference: 1794 Section 8.2 in [RFCthis] 1796 11.5.3. coap+ws 1798 IANA is requested to register the Uniform Resource Identifier (URI) 1799 scheme "coap+ws". This registration request complies with [RFC7595]. 1801 Scheme name: 1802 coap+ws 1804 Status: 1805 Permanent 1807 Applications/protocols that use this scheme name: 1808 The scheme is used by CoAP endpoints to access CoAP resources 1809 using the WebSocket protocol. 1811 Contact: 1812 IETF chair 1814 Change controller: 1815 IESG 1817 Reference: 1818 Section 8.3 in [RFCthis] 1820 11.5.4. coaps+ws 1822 IANA is requested to register the Uniform Resource Identifier (URI) 1823 scheme "coaps+ws". This registration request complies with 1824 [RFC7595]. 1826 Scheme name: 1827 coaps+ws 1829 Status: 1830 Permanent 1832 Applications/protocols that use this scheme name: 1833 The scheme is used by CoAP endpoints to access CoAP resources 1834 using the WebSocket protocol secured with TLS. 1836 Contact: 1837 IETF chair 1839 Change controller: 1840 IESG 1842 References: 1843 Section 8.4 in [RFCthis] 1845 11.6. Well-Known URI Suffix Registration 1847 IANA is requested to register the 'coap' well-known URI in the "Well- 1848 Known URIs" registry. This registration request complies with 1849 [RFC5785]: 1851 URI Suffix. 1852 coap 1854 Change controller. 1855 IETF 1857 Specification document(s). 1858 [RFCthis] 1860 Related information. 1861 None. 1863 11.7. ALPN Protocol Identifier 1865 IANA is requested to assign the following value in the registry 1866 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created 1867 by [RFC7301]. The "coap" string identifies CoAP when used over TLS. 1869 Protocol. 1870 CoAP 1872 Identification Sequence. 1873 0x63 0x6f 0x61 0x70 ("coap") 1875 Reference. 1876 [RFCthis] 1878 11.8. WebSocket Subprotocol Registration 1880 IANA is requested to register the WebSocket CoAP subprotocol under 1881 the "WebSocket Subprotocol Name Registry": 1883 Subprotocol Identifier. 1884 coap 1886 Subprotocol Common Name. 1888 Constrained Application Protocol (CoAP) 1890 Subprotocol Definition. 1891 [RFCthis] 1893 11.9. CoAP Option Numbers Registry 1895 IANA is requested to add [RFCthis] to the references for the 1896 following entries registered by [RFC7959] in the "CoAP Option 1897 Numbers" sub-registry defined by [RFC7252]: 1899 +--------+--------+---------------------+ 1900 | Number | Name | Reference | 1901 +--------+--------+---------------------+ 1902 | 23 | Block2 | RFC 7959, [RFCthis] | 1903 | | | | 1904 | 27 | Block1 | RFC 7959, [RFCthis] | 1905 +--------+--------+---------------------+ 1907 Table 3: CoAP Option Numbers 1909 12. References 1911 12.1. Normative References 1913 [I-D.bormann-hybi-ws-wk] 1914 Bormann, C., "Well-known URIs for the WebSocket Protocol", 1915 draft-bormann-hybi-ws-wk-00 (work in progress), May 2017. 1917 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1918 RFC 793, DOI 10.17487/RFC0793, September 1981, 1919 . 1921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1922 Requirement Levels", BCP 14, RFC 2119, 1923 DOI 10.17487/RFC2119, March 1997, 1924 . 1926 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1927 Resource Identifier (URI): Generic Syntax", STD 66, 1928 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1929 . 1931 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1932 (TLS) Protocol Version 1.2", RFC 5246, 1933 DOI 10.17487/RFC5246, August 2008, 1934 . 1936 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1937 Uniform Resource Identifiers (URIs)", RFC 5785, 1938 DOI 10.17487/RFC5785, April 2010, 1939 . 1941 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1942 Extensions: Extension Definitions", RFC 6066, 1943 DOI 10.17487/RFC6066, January 2011, 1944 . 1946 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1947 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1948 . 1950 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1951 Application Protocol (CoAP)", RFC 7252, 1952 DOI 10.17487/RFC7252, June 2014, 1953 . 1955 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1956 "Transport Layer Security (TLS) Application-Layer Protocol 1957 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1958 July 2014, . 1960 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1961 "Recommendations for Secure Use of Transport Layer 1962 Security (TLS) and Datagram Transport Layer Security 1963 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1964 2015, . 1966 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1967 and Registration Procedures for URI Schemes", BCP 35, 1968 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1969 . 1971 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1972 Application Protocol (CoAP)", RFC 7641, 1973 DOI 10.17487/RFC7641, September 2015, 1974 . 1976 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1977 Security (TLS) / Datagram Transport Layer Security (DTLS) 1978 Profiles for the Internet of Things", RFC 7925, 1979 DOI 10.17487/RFC7925, July 2016, 1980 . 1982 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1983 the Constrained Application Protocol (CoAP)", RFC 7959, 1984 DOI 10.17487/RFC7959, August 2016, 1985 . 1987 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1988 Writing an IANA Considerations Section in RFCs", BCP 26, 1989 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1990 . 1992 12.2. Informative References 1994 [BK2015] Byrne, C. and J. Kleberg, "Advisory Guidelines for UDP 1995 Deployment", Proceedings draft-byrne-opsec-udp-advisory-00 1996 (expired), 2015. 1998 [EK2016] Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 1999 B. Donnet, "Using UDP for Internet Transport Evolution", 2000 Proceedings arXiv preprint 1612.07816, 2016. 2002 [HomeGateway] 2003 Eggert, L., "An experimental study of home gateway 2004 characteristics", Proceedings of the 10th annual 2005 conference on Internet measurement , 2010. 2007 [I-D.gomez-lwig-tcp-constrained-node-networks] 2008 Gomez, C., Crowcroft, J., and M. Scharf, "TCP over 2009 Constrained-Node Networks", draft-gomez-lwig-tcp- 2010 constrained-node-networks-03 (work in progress), June 2011 2017. 2013 [I-D.ietf-core-cocoa] 2014 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 2015 "CoAP Simple Congestion Control/Advanced", draft-ietf- 2016 core-cocoa-02 (work in progress), October 2017. 2018 [I-D.ietf-core-object-security] 2019 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2020 "Object Security for Constrained RESTful Environments 2021 (OSCORE)", draft-ietf-core-object-security-07 (work in 2022 progress), November 2017. 2024 [IANA.uri-schemes] 2025 IANA, "Uniform Resource Identifier (URI) Schemes", 2026 . 2028 [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine 2029 Technical Specification Version 1.0", February 2017, 2030 . 2034 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2035 DOI 10.17487/RFC0768, August 1980, 2036 . 2038 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2039 Specifications: ABNF", STD 68, RFC 5234, 2040 DOI 10.17487/RFC5234, January 2008, 2041 . 2043 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2044 Cheshire, "Internet Assigned Numbers Authority (IANA) 2045 Procedures for the Management of the Service Name and 2046 Transport Protocol Port Number Registry", BCP 165, 2047 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2048 . 2050 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2051 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2052 January 2012, . 2054 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2055 Protocol (HTTP/1.1): Message Syntax and Routing", 2056 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2057 . 2059 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2060 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2061 DOI 10.17487/RFC7540, May 2015, 2062 . 2064 [SecurityChallenges] 2065 Polk, T. and S. Turner, "Security Challenges for the 2066 Internet of Things", Interconnecting Smart Objects with 2067 the Internet / IAB Workshop , February 2011, 2068 . 2071 [SW2016] Swett, I., "QUIC Deployment Experience @Google", 2072 Proceedings 2073 https://www.ietf.org/proceedings/96/slides/slides-96-quic- 2074 3.pdf, 2016. 2076 Appendix A. CoAP over WebSocket Examples 2078 This section gives examples for the first two configurations 2079 discussed in Section 4. 2081 An example of the process followed by a CoAP client to retrieve the 2082 representation of a resource identified by a "coap+ws" URI might be 2083 as follows. Figure 17 below illustrates the WebSocket and CoAP 2084 messages exchanged in detail. 2086 1. The CoAP client obtains the URI , for example, from a resource representation 2088 that it retrieved previously. 2090 2. It establishes a WebSocket connection to the endpoint URI 2091 composed of the authority "example.org" and the well-known path 2092 "/.well-known/coap", . 2094 3. CSM messages (Section 5.3) are exchanged (not shown for lack of 2095 space). 2097 4. It sends a single-frame, masked, binary message containing a CoAP 2098 request. The request indicates the target resource with the Uri- 2099 Path ("sensors", "temperature") and Uri-Query ("u=Cel") options. 2101 5. It waits for the server to return a response. 2103 6. The CoAP client uses the connection for further requests, or the 2104 connection is closed. 2106 CoAP CoAP 2107 Client Server 2108 (WebSocket (WebSocket 2109 Client) Server) 2111 | | 2112 | | 2113 +=========>| GET /.well-known/coap HTTP/1.1 2114 | | Host: example.org 2115 | | Upgrade: websocket 2116 | | Connection: Upgrade 2117 | | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 2118 | | Sec-WebSocket-Protocol: coap 2119 | | Sec-WebSocket-Version: 13 2120 | | 2121 |<=========+ HTTP/1.1 101 Switching Protocols 2122 | | Upgrade: websocket 2123 | | Connection: Upgrade 2124 | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 2125 | | Sec-WebSocket-Protocol: coap 2126 : : 2127 :<-------->: Exchange of CSM messages (not shown) 2128 | | 2129 +--------->| Binary frame (opcode=%x2, FIN=1, MASK=1) 2130 | | +-------------------------+ 2131 | | | GET | 2132 | | | Token: 0x53 | 2133 | | | Uri-Path: "sensors" | 2134 | | | Uri-Path: "temperature" | 2135 | | | Uri-Query: "u=Cel" | 2136 | | +-------------------------+ 2137 | | 2138 |<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0) 2139 | | +-------------------------+ 2140 | | | 2.05 Content | 2141 | | | Token: 0x53 | 2142 | | | Payload: "22.3 Cel" | 2143 | | +-------------------------+ 2144 : : 2145 : : 2146 +--------->| Close frame (opcode=%x8, FIN=1, MASK=1) 2147 | | 2148 |<---------+ Close frame (opcode=%x8, FIN=1, MASK=0) 2149 | | 2151 Figure 17: A CoAP client retrieves the representation of a resource 2152 identified by a "coap+ws" URI 2154 Figure 18 shows how a CoAP client uses a CoAP forward proxy with a 2155 WebSocket endpoint to retrieve the representation of the resource 2156 "coap://[2001:db8::1]/". The use of the forward proxy and the 2157 address of the WebSocket endpoint are determined by the client from 2158 local configuration rules. The request URI is specified in the 2159 Proxy-Uri Option. Since the request URI uses the "coap" URI scheme, 2160 the proxy fulfills the request by issuing a Confirmable GET request 2161 over UDP to the CoAP server and returning the response over the 2162 WebSocket connection to the client. 2164 CoAP CoAP CoAP 2165 Client Proxy Server 2166 (WebSocket (WebSocket (UDP 2167 Client) Server) Endpoint) 2169 | | | 2170 +--------->| | Binary frame (opcode=%x2, FIN=1, MASK=1) 2171 | | | +------------------------------------+ 2172 | | | | GET | 2173 | | | | Token: 0x7d | 2174 | | | | Proxy-Uri: "coap://[2001:db8::1]/" | 2175 | | | +------------------------------------+ 2176 | | | 2177 | +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54) 2178 | | | +------------------------------------+ 2179 | | | | GET | 2180 | | | | Token: 0x0a15 | 2181 | | | +------------------------------------+ 2182 | | | 2183 | |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54) 2184 | | | +------------------------------------+ 2185 | | | | 2.05 Content | 2186 | | | | Token: 0x0a15 | 2187 | | | | Payload: "ready" | 2188 | | | +------------------------------------+ 2189 | | | 2190 |<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0) 2191 | | | +------------------------------------+ 2192 | | | | 2.05 Content | 2193 | | | | Token: 0x7d | 2194 | | | | Payload: "ready" | 2195 | | | +------------------------------------+ 2196 | | | 2198 Figure 18: A CoAP client retrieves the representation of a resource 2199 identified by a "coap" URI via a WebSocket-enabled CoAP proxy 2201 Appendix B. Change Log 2203 The RFC Editor is requested to remove this section at publication. 2205 B.1. Since draft-ietf-core-coap-tcp-tls-02 2207 Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann- 2208 core-block-bert-01 Merged draft-bormann-core-coap-sig-02 2210 B.2. Since draft-ietf-core-coap-tcp-tls-03 2212 Editorial updates 2214 Added mandatory exchange of Capabilities and Settings messages after 2215 connecting 2217 Added support for coaps+tcp port 5684 and more details on 2218 Application-Layer Protocol Negotiation (ALPN) 2220 Added guidance on CoAP Signaling Ping-Pong versus WebSocket Ping-Pong 2222 Updated references and requirements for TLS security considerations 2224 B.3. Since draft-ietf-core-coap-tcp-tls-04 2226 Updated references 2228 Added Appendix: Updates to RFC7641 Observing Resources in the 2229 Constrained Application Protocol (CoAP) 2231 Updated Capability and Settings Message (CSM) exchange in the Opening 2232 Handshake to allow initiator to send messages before receiving 2233 acceptor CSM 2235 B.4. Since draft-ietf-core-coap-tcp-tls-05 2237 Addressed feedback from Working Group Last Call 2239 Added Securing CoAP section and informative reference to OSCOAP 2241 Removed the Server-Name and Bad-Server-Name Options 2243 Clarified the Capability and Settings Message (CSM) exchange 2245 Updated Pong response requirements 2247 Added Connection Initiator and Connection Acceptor terminology where 2248 appropriate 2249 Updated LWM2M 1.0 informative reference 2251 B.5. Since draft-ietf-core-coap-tcp-tls-06 2253 Addressed feedback from second Working Group Last Call 2255 B.6. Since draft-ietf-core-coap-tcp-tls-07 2257 Addressed feedback from IETF Last Call 2259 Addressed feedback from ARTART review 2261 Addressed feedback from GENART review 2263 Addressed feedback from TSVART review 2265 Added fragment identifiers to URI schemes 2267 Added "Updates RFC7959" for BERT 2269 Added "Updates RFC6455" to extend well-known URI mechanism to ws and 2270 wss 2272 Clarified well-known URI mechanism use for all URI schemes 2274 Changed NoSec to optional-to-implement 2276 Acknowledgements 2278 We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier 2279 Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, 2280 Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran 2281 Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu 2282 Wei for their feedback. 2284 Last-call reviews from Yoshifumi Nishida, Mark Nottingham, and Meral 2285 Shirazipour as well as several IESG reviewers provided extensive 2286 comments; from the IESG, we would like to specifically call out Ben 2287 Campbell, Mirja Kuehlewind, Eric Rescorla, Adam Roach, and the 2288 responsible AD Alexey Melnikov. 2290 Contributors 2291 Matthias Kovatsch 2292 Siemens AG 2293 Otto-Hahn-Ring 6 2294 Munich D-81739 2296 Phone: +49-173-5288856 2297 EMail: matthias.kovatsch@siemens.com 2299 Teemu Savolainen 2300 Nokia Technologies 2301 Hatanpaan valtatie 30 2302 Tampere FI-33100 2303 Finland 2305 Email: teemu.savolainen@nokia.com 2307 Valik Solorzano Barboza 2308 Zebra Technologies 2309 820 W. Jackson Blvd. Suite 700 2310 Chicago 60607 2311 United States of America 2313 Phone: +1-847-634-6700 2314 Email: vsolorzanobarboza@zebra.com 2316 Authors' Addresses 2318 Carsten Bormann 2319 Universitaet Bremen TZI 2320 Postfach 330440 2321 Bremen D-28359 2322 Germany 2324 Phone: +49-421-218-63921 2325 Email: cabo@tzi.org 2327 Simon Lemay 2328 Zebra Technologies 2329 820 W. Jackson Blvd. Suite 700 2330 Chicago 60607 2331 United States of America 2333 Phone: +1-847-634-6700 2334 Email: slemay@zebra.com 2335 Hannes Tschofenig 2336 ARM Ltd. 2337 110 Fulbourn Rd 2338 Cambridge CB1 9NJ 2339 Great Britain 2341 Email: Hannes.tschofenig@gmx.net 2342 URI: http://www.tschofenig.priv.at 2344 Klaus Hartke 2345 Universitaet Bremen TZI 2346 Postfach 330440 2347 Bremen D-28359 2348 Germany 2350 Phone: +49-421-218-63905 2351 Email: hartke@tzi.org 2353 Bilhanan Silverajan 2354 Tampere University of Technology 2355 Korkeakoulunkatu 10 2356 Tampere FI-33720 2357 Finland 2359 Email: bilhanan.silverajan@tut.fi 2361 Brian Raymor (editor) 2363 Email: brianraymor@hotmail.com