idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-07.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 289 has weird spacing: '...ntifier ide...' -- The document date (December 17, 2014) is 3418 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC7390' is defined on line 652, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-appsawg-uri-scheme-reg-04 == Outdated reference: A later version (-06) exists of draft-becker-core-coap-sms-gprs-05 == Outdated reference: A later version (-17) exists of draft-ietf-6lo-btle-03 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-15 == Outdated reference: A later version (-10) exists of draft-jimenez-p2psip-coap-reload-04 == Outdated reference: A later version (-07) exists of draft-savolainen-core-coap-websockets-03 == Outdated reference: A later version (-05) exists of draft-tschofenig-core-coap-tcp-tls-01 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group B. Silverajan 3 Internet-Draft Tampere University of Technology 4 Intended status: Informational T. Savolainen 5 Expires: June 20, 2015 Nokia 6 December 17, 2014 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-07 11 Abstract 13 CoAP has been standardised as an application level REST-based 14 protocol. A single CoAP message is typically encapsulated and 15 transmitted using UDP or DTLS as transports. These transports are 16 optimal solutions for CoAP use in IP-based constrained environments 17 and nodes. However compelling motivation exists for understanding 18 how CoAP can operate with other transports, such as the need for M2M 19 communication using non-IP networks, improved transport level end-to- 20 end reliability and security, NAT and firewall traversal issues, and 21 mechanisms possibly incurring a lower overhead to CoAP/HTTP 22 translation gateways. This draft examines the requirements for 23 conveying CoAP messages to end points over such alternative 24 transports. It also provides a new URI format for representing CoAP 25 resources over alternative transports. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 20, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Usage Cases . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Use of SMS . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Use of WebSockets . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Use of P2P Overlays . . . . . . . . . . . . . . . . . . . 4 66 2.4. Use of TCP and TLS . . . . . . . . . . . . . . . . . . . 4 67 2.5. Others . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Node Types based on Transport Availability . . . . . . . . . 5 69 4. CoAP Alternative Transport URI . . . . . . . . . . . . . . . 6 70 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 7 71 4.2. URI format . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Alternative Transport Analysis and Properties . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 9.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Appendix A. Expressing transport in the URI in other ways . . . 15 80 A.1. Transport information as part of the URI authority . . . 15 81 A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 16 82 A.2. Making CoAP Resources Available over Multiple Transports 16 83 A.3. Transport as part of a 'service:' URL scheme . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 The Constrained Application Protocol (CoAP) [RFC7252] has been 89 standardised by the CoRE WG as a lightweight, HTTP-like protocol 90 providing a request/response model that constrained nodes can use to 91 communicate with other nodes, be those servers, proxies, gateways, 92 less constrained nodes, or other constrained nodes. 94 As the Internet continues taking shape by integrating new kinds of 95 networks, services and devices, the need for a consistent, 96 lightweight method for resource representation, retrieval and 97 manipulation becomes evident. Owing to its simplicity and low 98 overhead, CoAP is a highly suitable protocol for this purpose. 99 However, the CoAP endpoint can reside in a non-IP network, be 100 separated from its peer by NATs and firewalls or simply has no 101 possibility to communicate over UDP. Consequently in addition to 102 UDP, alternative transport channels for conveying CoAP messages could 103 be considered. 105 Extending CoAP over alternative transports allows implementations to 106 have a significantly larger relevance in constrained as well as non- 107 constrained networked environments. It leads to better code 108 optimisation in constrained nodes and broader implementation reuse 109 across new transport channels. As opposed to implementing new 110 resource retrieval mechanisms, an application in an end-node can 111 continue relying on using CoAP's REST-based resource retrieval and 112 manipulation for this purpose, while changes in end point 113 identification and the transport protocol can be addressed by a 114 transport-specific messaging sublayer. This simplifies development 115 and memory requirements. Resource representations are also visible 116 in an end-to-end manner for any CoAP client. The processing and 117 computational overhead for conveying CoAP Requests and Responses from 118 one underlying transport to another, would be less than that of an 119 application-level gateway performing protocol translation of 120 individual messages between CoAP and another resource retrieval 121 protocol such as HTTP. 123 This document first provides scenarios where usage of CoAP over 124 alternative transports is either currently underway, or may prove 125 advantageous in the future. A simple transport type classification 126 for CoAP-capable nodes is provided next. Then a new URI format is 127 described through which a CoAP resource representation can be 128 formulated that expresses transport identification in addition to 129 endpoint information and resource paths. Following that, a 130 discussion of the various transport properties which influence how 131 CoAP Requests and Responses are mapped to transport level payloads, 132 is presented. 134 This document however, does not touch on application QoS 135 requirements, user policies or network adaptation, nor does it 136 advocate replacing the current practice of UDP-based CoAP 137 communication. 139 2. Usage Cases 141 Apart from UDP and DTLS, CoAP usage is being specified for the 142 following environments as of this writing: 144 2.1. Use of SMS 146 CoAP Request and Response messages can be sent via SMS between CoAP 147 end-points in a cellular network [I-D.becker-core-coap-sms-gprs]. A 148 CoAP Request message can also be sent via SMS from a CoAP client to a 149 sleeping CoAP Server as a wake-up mechanism and trigger communication 150 via IP. The Open Mobile Alliance (OMA) specifies both UDP and SMS as 151 transports for M2M communication in cellular networks. The OMA 152 Lightweight M2M protocol being drafted uses CoAP, and as transports, 153 specifies both UDP binding as well as Short Message Service (SMS) 154 bindings [OMALWM2M] for the same reason. For securing end-to-end 155 communication between Mobile Stations, the use of DTLS-encoded CoAP 156 messages over SMS is also being proposed 157 [I-D.fossati-dtls-over-gsm-sms]. 159 2.2. Use of WebSockets 161 The WebSocket protocol is being proposed as a transport channel 162 between WebSocket enabled CoAP end-points on the Internet 163 [I-D.savolainen-core-coap-websockets]. This is particularly useful 164 as a means for web browsers, especially in smart devices, to allow 165 embedded client side scripts to create new WebSocket connections to 166 various WebSocket-enabled servers, through which CoAP Request and 167 Response messages can be exchanged. This also allows a browser 168 containing an embedded CoAP server to behave as a WebSocket client by 169 opening a connection to a WebSocket enabled CoAP Mirror Server 170 [I-D.vial-core-mirror-server] to register and update its resources. 172 2.3. Use of P2P Overlays 174 [I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can use a 175 peer-to-peer overlay network called RELOAD, as a resource caching 176 facility for storing wireless sensor data. When a CoAP node 177 registers its resources with a RELOAD Proxy Node (PN), the node 178 computes a hash value from the CoAP URI and stores it as a structure 179 together with the PN's Node ID as well as the resources. Resource 180 retrieval by CoAP nodes is accomplished by computing the hash key 181 over the Request URI,opening a connection to the overlay and using 182 its message routing system to contact the CoAP server via its PN. 184 2.4. Use of TCP and TLS 186 Using TCP to facilitate the traversal of CoAP Request and Response 187 messages 188 [I-D.bormann-core-coap-tcp][I-D.tschofenig-core-coap-tcp-tls], allows 189 easier communication between CoAP clients and servers separated by 190 firewalls and NATs. This also allows CoAP messages to be transported 191 over push notification services from a notification server to a 192 client app on a smartphone, that may previously have subscribed to 193 receive change notifications of CoAP resource representations, 194 possibly by using CoAP Observe-functionality [I-D.ietf-core-observe]. 195 [I-D.tschofenig-core-coap-tcp-tls] also discusses using TLS as a 196 transport to securely convey CoAP messages over TCP. 198 2.5. Others 200 CoAP could in addition be extended atop other transport channels, 201 such as: 203 1. The transportation of CoAP messages in Delay-Tolerant Networks 204 [RFC4838], using the Bundle Protocol [RFC5050] for reaching 205 sensors in extremely challenging environments such as acoustic, 206 underwater and deep space networks. 208 2. Any type of non-IP networks supporting constrained nodes and low- 209 energy sensors, such as Bluetooth and Bluetooth Low Energy 210 (either through L2CAP or with GATT) [BTCorev4.1], ZigBee, Z-Wave, 211 1-Wire, DASH7 and so on. 213 3. Instant Messaging and Social Networking channels, such as Jabber 214 and Twitter. 216 3. Node Types based on Transport Availability 218 The term "alternative transport" in this document thus far has been 219 used to refer to any non-UDP and non-DTLS transport that can convey 220 CoAP messages in its payload. A node however, may in fact possess 221 the capability to utilise CoAP over multiple transport channels at 222 its disposal, simultaneously or otherwise, at any point in time to 223 communicate with a CoAP end-point. Such communication can obviously 224 take place over UDP and DTLS as well. Inevitably, if two CoAP 225 endpoints reside in distinctly separate networks with orthogonal 226 transports, a CoAP proxy node is needed between the two networks so 227 that CoAP Requests and Responses can be exchanged properly. 229 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 230 devices, in terms of their resource constraints, energy limitations 231 and communication power. For this document, in addition to these 232 capabilities, it seems useful to additionally identify devices based 233 on their transport capabilities. 235 +-------+----------------------------+ 236 | Name | Transport Availability | 237 +-------+----------------------------+ 238 | T0 | Single transport | 239 | | | 240 | T1 | Multiple transports, with | 241 | | one or more active at any | 242 | | point in time | 243 | | | 244 | T2 | Multiple active transports| 245 +-------+----------------------------+ 247 Table 1: Classes of Available Transports 249 Nodes falling under Type T0 possess the capability of exactly 1 type 250 of transport channel for CoAP, at all times. These include both 251 active and sleepy nodes, which may choose to perform duty cycling for 252 power saving. 254 Type T1 nodes possess multiple different transports, and can retrieve 255 or expose CoAP resources over any or all of these transports. 256 However, not all transports are constantly active and certain 257 transport channels and interfaces could be kept in a mostly-off state 258 for energy-efficiency, such as when using CoAP over SMS (refer to 259 section 2.1) 261 Type T2 nodes possess more than 1 transport, and multiple transports 262 are simultaneously active at all times. CoAP proxy nodes which allow 263 CoAP endpoints from disparate transports to communicate with each 264 other, are a good example of this. 266 4. CoAP Alternative Transport URI 268 Based on the usage scenarios as well as the transport classes 269 presented in the preceding sections, this section discusses the 270 formulation of a new URI for representing CoAP resources over 271 alternative transports. 273 CoAP is logically divided into 2 sublayers, whereby a request/ 274 response layer is responsible for the protocol functionality of 275 exchanging request and response messages, while the messaging layer 276 is bound to UDP. These 2 sublayers are tightly coupled, both being 277 responsible for properly encoding the header and body of the CoAP 278 message. The CoAP URI is used by both logical sublayers. For a URI 279 that is expressed generically as 281 URI = scheme ":" "//" authority path-abempty ["?"query ] 282 a simple example CoAP URI, "coap://server.example.com/sensors/ 283 temperature" is interpreted as follows: 285 coap :// server.example.com /sensors/temperature 286 \___/ \______ ________/ \______ _________/ 287 | \/ \/ 288 protocol endpoint parameterised 289 identifier identifier resource 290 identifier 292 Figure 1: The CoAP URI format 294 The resource path is explicitly expressed, and the endpoint 295 identifier, which contains the host address at the network-level is 296 also directly bound to the scheme name containing the application- 297 level protocol identifier. The choice of a specific transport for a 298 scheme, however, cannot be embedded with a URI, but is defined by 299 convention or standardisation of the protocol using the scheme. As 300 examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol 301 over TCP, while [RFC2818] requires that the 'https' protocol 302 identifier be used to differentiate using HTTP over TLS instead of 303 TCP. 305 4.1. Design Considerations 307 Several ways of formulating a URI which express an alternative 308 transport binding to CoAP, can be envisioned. When such a URI is 309 provided from an end-application to its CoAP implementation, the URI 310 component containing transport-specific information can be checked to 311 allow CoAP to use the appropriate transport for a target endpoint 312 identifier. 314 The following design considerations influence the formulation of a 315 new URI expressing CoAP resources over alternative transports: 317 1. A CoAP Transport URI can be supplied as a Proxy-Uri option by a 318 CoAP end-point to a CoAP forward proxy. This allows 319 communication with a CoAP end-point residing in a network using a 320 different transport. Section 6.4 of [RFC7252] provides an 321 algorithm for parsing a received URI to obtain the request's 322 options. Also, the generic syntax for a URI is described in 323 [RFC3986]. By ensuring conformance to RFC3986, the need for 324 custom URI parsers as well as resolution algorithms can be 325 obviated. In particular, a URI format needs to be described in 326 which each URI component clearly meets the syntax and percent- 327 encoding rules described. 329 2. Request messages sent to a CoAP endpoint using a CoAP Transport 330 URI may be responded to with a relative URI reference, for 331 example, of the form "../../path/to/resource". In such cases, 332 the requesting endpoint needs to resolve the relative reference 333 against the original CoAP Transport URI to then obtain a new 334 target URI to which a request can be sent to, to obtain a 335 resource representation. [RFC3986] provides an algorithm to 336 establish how relative references can be resolved against a base 337 URI to obtain a target URI. Given this algorithm, a URI format 338 needs to be described in which relative reference resolution does 339 not result in a target URI that loses its transport-specific 340 information 342 3. The host component of current CoAP URIs can either be an IPv4 343 address, an IPv6 address or a resolvable hostname. While the 344 usage of DNS can sometimes be useful for distinguishing transport 345 information (see section 4.3.1), accessing DNS over some 346 alternative transport environments may be challenging. 347 Therefore, a URI format needs to be described which is able to 348 represent a resource without heavy reliance on a naming 349 infrastructure, such as DNS. 351 4.2. URI format 353 To meet the design considerations previously discussed, the transport 354 information is expressed as part of the URI scheme component. This 355 is performed by minting new schemes for alternative transports using 356 the form "coap+" and/or "coaps+", 357 where the name of the transport is clearly and unambiguously 358 described. Each scheme name formed in this manner is used to 359 differentiate the use of CoAP, or CoAP using DTLS, over an 360 alternative transport respectively. The endpoint identifier, path 361 and query components together with each scheme name would be used to 362 uniquely identify each resource. 364 Examples of such URIs are: 366 o coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP 367 over TCP 369 o coap+tls://[2001:db8::1]:5683/sensors/temperature for using CoAP 370 over TLS 372 o coaps+sctp://[2001:db8::1]:5683/sensors/temperature for using CoAP 373 over DTLS over SCTP 375 o coap+sms://0015105550101/sensors/temperature for using CoAP over 376 SMS with the endpoint identifier being a telephone subscriber 377 number 379 o coaps+sms://0015105550101/sensors/temperature for using CoAP over 380 DTLS over SMS with the endpoint identifier being a telephone 381 subscriber number 383 o coap+ws://www.example.com/sensors/temperature for using CoAP over 384 WebSockets 386 o coap+wss://www.example.com/sensors/temperature for using CoAP over 387 secure WebSockets (WebSockets using TLS) 389 A URI of this format to distinguish transport types is simple to 390 understand and not dissimilar to the CoAP URI format. As the usage 391 of each alternative transport results in an entirely new scheme, IANA 392 intervention is required for the registration of each scheme name. 393 The registration process follows the guidelines stipulated in 394 [I-D.ietf-appsawg-uri-scheme-reg], particularly where permanent URI 395 scheme registration is concerned. 397 It is also entirely possible for each new scheme to specify its own 398 rules for how resource and transport endpoint information can be 399 presented. However, the URIs and resource representations arising 400 from their usage should meet the URI design considerations and 401 guidelines mentioned in this document. In addition, each new 402 transport being defined should take into consideration the various 403 transport-level properties that can have an impact on how CoAP 404 messages are conveyed as payload. This is elaborated on in the next 405 section. 407 5. Alternative Transport Analysis and Properties 409 In this section the various characteristics of alternative transports 410 for successfully supporting various kinds of functionality for CoAP 411 are considered. CoAP factors lossiness, unreliability, small packet 412 sizes and connection statelessness into its protocol logic. General 413 transport differences and their impact on carrying CoAP messages here 414 are discussed. Note that Properties 1, 2, and 3 are related. 416 Property 1: Uniqueness of an end-point identifier. 418 Transport protocols providing non-unique end-point IDs for nodes may 419 only convey a subset of the CoAP functionality. Such nodes may only 420 serve as CoAP servers that announce data at specific intervals to a 421 pre-specified end point, or to a shared medium. 423 Property 2: Unidirectional or bidirectional CoAP communication 424 support. 426 This refers to the ability of the CoAP end-point to use a single 427 transport channel for both request and response messages. Depending 428 on the scenario, having a unidirectional transport layer would mean 429 the CoAP end-point might utilise it only for outgoing data or 430 incoming data. Should both functionalities be needed, 2 431 unidirectional transport channels would be necessary. 433 Property 3: 1:N communication support. 435 This refers to the ability of the transport protocol to support 436 broadcast and multicast communication. CoAP's request/response 437 behaviour depends on unicast messaging. Group communication in CoAP 438 is bound to using multicasting. Therefore a protocol such as TCP 439 would be ill-suited for group communications using multicast. 440 Anycast support, where a message is sent to a well defined 441 destination address to which several nodes belong, on the other hand, 442 is supported by TCP. 444 Property 4: Transport-level reliability. 446 This refers to the ability of the transport protocol to provide a 447 guarantee of reliability against packet loss, ensuring ordered packet 448 delivery and having error control. When CoAP Request and Response 449 messages are delivered over such transports, the CoAP implementations 450 elide certain fields in the packet header. As an example, if the 451 usage of a connection-oriented transport renders it unnecessary to 452 specify the various CoAP message types, the Type field can be elided. 453 For some connection-oriented transports, such as WebSockets, the 454 version of CoAP being used can be negotiated during the opening 455 transfer. Consequently, the Version field in CoAP packets can also 456 be elided. 458 Property 5: Message encoding. 460 While parts of the CoAP payload are human readable or are transmitted 461 in XML, JSON or SenML format, CoAP is essentially a low overhead 462 binary protocol. Efficient transmission of such packets would 463 therefore be met with a transport offering binary encoding support, 464 although techniques exist in allowing binary payloads to be 465 transferred over text-based transport protocols such as base-64 466 encoding. A fuller discussion about performing CoAP message encoding 467 for SMS can be found in Appendix A.5 of [I-D.bormann-coap-misc] 469 Property 6: Network byte order. 471 CoAP, as well as transports based on the IP stack use a Big Endian 472 byte order for transmitting packets over the air or wire, while 473 transports based on Bluetooth and Zigbee prefer Little Endian byte 474 ordering for packet fields and transmission. Any CoAP implementation 475 that potentially uses multiple transports has to ensure correct byte 476 ordering for the transport used. 478 Property 7: MTU correlation with CoAP PDU size. 480 Section 4.6 of [RFC7252] discusses the avoidance of IP fragmentation 481 by ensuring CoAP message fit into a single UDP datagram. End-points 482 on constrained networks using 6LoWPAN may use blockwise transfers to 483 accommodate even smaller packet sizes to avoid fragmentation. The 484 MTU sizes for Bluetooth Low Energy as well as Classic Bluetooth are 485 provided in Section 2.4 of [I-D.ietf-6lo-btle]. Transport MTU 486 correlation with CoAP messages helps ensure minimal to no 487 fragmentation at the transport layer. On the other hand, allowing a 488 CoAP message to be delivered using a delay-tolerant transport service 489 such as the Bundle Protocol [RFC5050] would imply that the CoAP 490 message may be fragmented (or reconstituted) along various nodes in 491 the DTN as various sized bundles and bundle fragments. 493 Property 8: Framing 495 When using CoAP over a streaming transport protocol such as TCP, as 496 opposed to datagram based protocols, care must be observed in 497 preserving message boundaries. Commonly applied techniques at the 498 transport level include the use of delimiting characters for this 499 purpose as well as message framing and length prefixing. 501 Property 9: Transport latency. 503 A confirmable CoAP request would be retransmitted by a CoAP end-point 504 if a response is not obtained within a certain time. A CoAP end- 505 point registering to a Resource Directory uses a POST message that 506 could include a lifetime value. A sleepy end-point similarly uses a 507 lifetime value to indicate the freshness of the data to a CoAP Mirror 508 Server. Care needs to be exercised to ensure the latency of the 509 transport being used to carry CoAP messages is small enough not to 510 interfere with these values for the proper operation of these 511 functionalities. 513 Property 10: Connection Management. 515 A CoAP endpoint using a connection-oriented transport should be 516 responsible for proper connection establishment prior to sending a 517 CoAP Request message. Both communicating endpoints may monitor the 518 connection health during the Data Transfer phase. Finally, once data 519 transfer is complete, at least one end point should perform 520 connection teardown gracefully. 522 6. IANA Considerations 524 This memo includes no request to IANA. 526 7. Security Considerations 528 While no new security risks are envisaged simply from the 529 introduction of support for alternative transports, end-applications 530 and CoAP implementations should take note if certain transports 531 require privacy trade-offs that may arise if identifiers such as MAC 532 addresses or phone numbers are made public in addition to FQDNs. 534 8. Acknowledgements 536 Feedback, ideas and ongoing discussions with Klaus Hartke, Martin 537 Thomson, Mark Nottingham, Dave Thaler, Graham Klyne, Carsten Bormann, 538 Markus Becker and Golnaz Karbaschi provided useful insights and ideas 539 for this work. 541 9. References 543 9.1. Normative References 545 [I-D.ietf-appsawg-uri-scheme-reg] 546 Thaler, D., Hansen, T., Hardie, T., and L. Masinter, 547 "Guidelines and Registration Procedures for URI Schemes", 548 draft-ietf-appsawg-uri-scheme-reg-04 (work in progress), 549 October 2014. 551 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 552 Resource Identifier (URI): Generic Syntax", STD 66, RFC 553 3986, January 2005. 555 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 556 Constrained-Node Networks", RFC 7228, May 2014. 558 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 559 Application Protocol (CoAP)", RFC 7252, June 2014. 561 9.2. Informative References 563 [BTCorev4.1] 564 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 565 Version 4.1", December 2013. 567 [I-D.becker-core-coap-sms-gprs] 568 Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, 569 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 570 gprs-05 (work in progress), August 2014. 572 [I-D.bormann-coap-misc] 573 Bormann, C. and K. Hartke, "Miscellaneous additions to 574 CoAP", draft-bormann-coap-misc-27 (work in progress), 575 November 2014. 577 [I-D.bormann-core-coap-tcp] 578 Bormann, C., "A TCP transport for CoAP", draft-bormann- 579 core-coap-tcp-01 (work in progress), July 2014. 581 [I-D.fossati-dtls-over-gsm-sms] 582 Fossati, T. and H. Tschofenig, "Datagram Transport Layer 583 Security (DTLS) over Global System for Mobile 584 Communications (GSM) Short Message Service (SMS)", draft- 585 fossati-dtls-over-gsm-sms-01 (work in progress), October 586 2014. 588 [I-D.ietf-6lo-btle] 589 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 590 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 591 over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-03 592 (work in progress), September 2014. 594 [I-D.ietf-core-observe] 595 Hartke, K., "Observing Resources in CoAP", draft-ietf- 596 core-observe-15 (work in progress), October 2014. 598 [I-D.jimenez-p2psip-coap-reload] 599 Jimenez, J., Lopez-Vega, J., Maenpaa, J., and G. 600 Camarillo, "A Constrained Application Protocol (CoAP) 601 Usage for REsource LOcation And Discovery (RELOAD)", 602 draft-jimenez-p2psip-coap-reload-04 (work in progress), 603 July 2014. 605 [I-D.savolainen-core-coap-websockets] 606 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 607 WebSockets", draft-savolainen-core-coap-websockets-03 608 (work in progress), October 2014. 610 [I-D.tschofenig-core-coap-tcp-tls] 611 Lemay, S., Technologies, Z., and H. Tschofenig, "A TCP and 612 TLS Transport for the Constrained Application Protocol 613 (CoAP)", draft-tschofenig-core-coap-tcp-tls-01 (work in 614 progress), September 2014. 616 [I-D.vial-core-mirror-server] 617 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 618 server-01 (work in progress), April 2013. 620 [OMALWM2M] 621 Open Mobile Alliance (OMA), "Lightweight Machine to 622 Machine Technical Specification", 2013. 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 628 and Service: Schemes", RFC 2609, June 1999. 630 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 632 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 633 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 634 Networking Architecture", RFC 4838, April 2007. 636 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 637 Specification", RFC 5050, November 2007. 639 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 640 November 2007. 642 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 643 6455, December 2011. 645 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 646 Application Spaces for IPv6 over Low-Power Wireless 647 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 649 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 650 "Diameter Base Protocol", RFC 6733, October 2012. 652 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 653 Constrained Application Protocol (CoAP)", RFC 7390, 654 October 2014. 656 [WWWArchv1] 657 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 658 of the World Wide Web, Volume One", December 2004. 660 Appendix A. Expressing transport in the URI in other ways 662 Other means of indicating the transport as a distinguishable 663 component within the CoAP URI are possible, but have been deemed 664 unsuitable by not meeting the design considerations listed, or are 665 incompatible with existing practices outlined in [RFC7252]. They are 666 however, retained in this section for historical documentation and 667 completeness. 669 A.1. Transport information as part of the URI authority 671 A single URI scheme, "coap-at" can be introduced, as part of an 672 absolute URI which expresses the transport information within the 673 authority component. One approach is to structure the component with 674 a transport prefix to the endpoint identifier and a delimiter, such 675 as "-endpoint_identifier". 677 Examples of resulting URIs are: 679 o coap-at://tcp-server.example.com/sensors/temperature 681 o coap-at://sms-0015105550101/sensors/temperature 683 An implementation note here is that some generic URI parsers will 684 fail when encountering a URI such as "coap-at://tcp- 685 [2001:db8::1]/sensors/temperature". Consequently, an equivalent, but 686 parseable URI from the ip6.arpa domain needs to be formulated 687 instead. For [2001:db8::1] using TCP, this would result in the 688 following URL: 690 coap-at://tcp-1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0 691 .1.0.0.2.ip6.arpa:5683/sensors/temperature 693 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 694 similarly be expressed with a URI from the ip6.arpa domain. 696 This URI format allows the usage of a single scheme to represent 697 multiple types of transport end-points. Consequently, it requires 698 consistency in ensuring how various transport-specific endpoints are 699 identified, as a single URI format is used. Attention must be paid 700 towards the syntax rules and encoding for the URI host component. 701 Additionally, against a base URI of the form "coap-at://tcp- 702 server.example.com/sensors/temperature", resolving a relative 703 reference, such as "//example.net/sensors/temperature" would result 704 in the target URI "coap-at://example.net/sensors/temperature", in 705 which transport information is lost. 707 A.1.1. Usage of DNS records 709 DNS names can be used instead of IPv6 address literals to mitigate 710 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 711 possible. 713 DNS SRV records can also be employed to formulate a URL such as: 715 coap-at://srv-_coap._tcp.example.com/sensors/temperature 717 in which the "srv" prefix is used to indicate that a DNS SRV lookup 718 should be used for _coap._tcp.example.com, where usage of CoAP over 719 TCP is specified for example.com, and is eventually resolved to a 720 numerical IPv4 or IPv6 address. 722 A.2. Making CoAP Resources Available over Multiple Transports 724 The CoAP URI used thus far is as follows: 726 URI = scheme ":" hier-part [ "?" query ] 727 hier-part = "//" authority path-abempty 729 A new URI format could be introduced, that does not possess an 730 "authority" component, and instead defining "hier-part" to instead 731 use another component, "path-rootless", as specified by RFC3986 732 [RFC3986]. The partial ABNF format of this URI would then be: 734 URI = scheme ":" hier-part [ "?" query ] 735 hier-part = path-rootless 736 path-rootless = segment-nz *( "/" segment ) 738 The full syntax of "path-rootless" is described in [RFC3986]. A 739 generic URI defined this way would conform to the syntax of 740 [RFC3986], while the path component can be treated as an opaque 741 string to indicate transport types, endpoints as well as paths to 742 CoAP resources. A single scheme can similarly be used. 744 A constrained node that is capable of communicating over several 745 types of transports (such as UDP, TCP and SMS) would be able to 746 convey a single CoAP resource over multiple transports. This is also 747 beneficial for nodes performing caching and proxying from one type of 748 transport to another. 750 Requesting and retrieving the same CoAP resource representation over 751 multiple transports could be rendered possible by prefixing the 752 transport type and endpoint identifier information to the CoAP URI. 753 This would result in the following example representation: 755 coap-at:tcp://example.com?coap://example.com/sensors/temperature 756 \_______ ______/ \________________ __________________/ 757 \/ \/ 758 Transport-specific CoAP Resource 759 Prefix 761 Figure 2: Prefixing a CoAP URI with TCP transport 763 Such a representation would result in the URI being decomposed into 764 its constituent components, with the CoAP resource residing within 765 the query component as follows: 767 Scheme: coap-at 769 Path: tcp://example.com 771 Query: coap://example.com/sensors/temperature 773 The same CoAP resource, if requested over a WebSocket transport, 774 would result the following URI: 776 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 777 \___________ __________/ \_______________ ___________________/ 778 \/ \/ 779 Transport-specific CoAP Resource 780 Prefix 782 Figure 3: Prefixing a CoAP URI with WebSocket transport 784 While the transport prefix changes, the CoAP resource representation 785 remains the same in the query component: 787 Scheme: coap-at 789 Path: ws://example.com/endpoint 790 Query: coap://example.com/sensors/temperature 792 The URI format described here overcomes URI aliasing [WWWArchv1] when 793 multiple transports are used, by ensuring each CoAP resource 794 representation remains the same, but is prefixed with different 795 transports. However, against a base URI of this format, resolving 796 relative references of the form "//example.net/sensors/temperature" 797 and "/sensor2/temperature" would again result in target URIs which 798 lose transport-specific information. 800 Implementation note: While square brackets are disallowed within the 801 path component, the '[' and ']' characters needed to enclose a 802 literal IPv6 address can be percent-encoded into their respective 803 equivalents. The ':' character does not need to be percent-encoded. 804 This results in a significantly simpler URI string compared to 805 section 2.2, particularly for compressed IPv6 addresses. 806 Additionally, the URI format can be used to specify other similar 807 address families and formats, such as Bluetooth addresses 808 [BTCorev4.1]. 810 A.3. Transport as part of a 'service:' URL scheme 812 The "service:" URL scheme name was introduced in [RFC2609] and forms 813 the basis of service description used primarily by the Service 814 Location Protocol. An abstract service type URI would have the form 816 "service::" 818 where refers to a service type name that can be 819 associated with a variety of protocols, while the 820 then providing the specific details of the protocol used, authority 821 and other URI components. 823 Adopting the "service:" URL scheme to describe CoAP usage over 824 alternative transports would be rather trivial. To use a previous 825 example, a CoAP service to discover a Resource Directory and its base 826 RD resource using TCP would take the form 828 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 830 The syntax of the "service:" URL scheme differs from the generic URI 831 syntax and therefore such a representation should be treated as an 832 opaque URI as Section 2.1 of [RFC2609] recommends. 834 Authors' Addresses 836 Bilhanan Silverajan 837 Tampere University of Technology 838 Korkeakoulunkatu 10 839 FI-33720 Tampere 840 Finland 842 Email: bilhanan.silverajan@tut.fi 844 Teemu Savolainen 845 Nokia 846 Hermiankatu 12 D 847 FI-33720 Tampere 848 Finland 850 Email: teemu.savolainen@nokia.com