idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-08.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 272 has weird spacing: '...ntifier ide...' -- The document date (June 20, 2015) is 3233 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC4838' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 626, but no explicit reference was found in the text == 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-13 == Outdated reference: A later version (-10) exists of draft-jimenez-p2psip-coap-reload-09 == Outdated reference: A later version (-07) exists of draft-savolainen-core-coap-websockets-04 == Outdated reference: A later version (-05) exists of draft-tschofenig-core-coap-tcp-tls-04 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 12 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: December 22, 2015 Nokia 6 June 20, 2015 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-08 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 allowing CoAP to 18 operate with other transports and protocols. Examples are M2M 19 communication in cellular networks using SMS, more suitable transport 20 protocols for firewall/NAT traversal, end-to-end reliability and 21 security such as TCP and TLS, or employing proxying and tunneling 22 gateway techniques such as the WebSocket protocol. This draft 23 examines the requirements for conveying CoAP messages to end points 24 over such alternative transports. It also provides a new URI format 25 for representing CoAP 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 December 22, 2015. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 5 67 3. Node Types based on Transport Availability . . . . . . . . . 5 68 4. CoAP Alternative Transport URI . . . . . . . . . . . . . . . 6 69 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 7 70 4.2. URI format . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Alternative Transport Analysis and Properties . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Appendix A. Expressing transport in the URI in other ways . . . 14 79 A.1. Transport information as part of the URI authority . . . 14 80 A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 15 81 A.2. Making CoAP Resources Available over Multiple Transports 15 82 A.3. Transport as part of a 'service:' URL scheme . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The Constrained Application Protocol (CoAP) [RFC7252] has been 88 standardised by the CoRE WG as a lightweight, HTTP-like protocol 89 providing a request/response model that constrained nodes can use to 90 communicate with other nodes, be those servers, proxies, gateways, 91 less constrained nodes, or other constrained nodes. CoAP has been 92 definied to utilise UDP and DTLS as transports. 94 As the Internet evolves by integrating new kinds of networks, 95 services and devices, the need for a consistent, lightweight method 96 for resource representation, retrieval and manipulation becomes 97 evident. Owing to its simplicity and low overhead, CoAP is a highly 98 suitable protocol for this purpose. However, communicating CoAP 99 endpoints can reside in networks where end-to-end UDP-based 100 communication can be challenging. These include networks separated 101 by NATs and firewalls, cellular networks in which the Short Messaging 102 Service (SMS) can be utilised as between nodes, or simply situations 103 where an endpoint has no possibility to communicate over UDP. 104 Consequently in addition to UDP and DTLS, alternative transport 105 channels for conveying CoAP messages should be considered. 107 Extending CoAP over alternative transports allows CoAP 108 implementations to have a significantly larger relevance in 109 constrained as well as non-constrained networked environments: it 110 leads to better code optimisation in constrained nodes and broader 111 implementation reuse across new transport channels. As opposed to 112 implementing new resource retrieval mechanisms, an application in an 113 end-node can continue relying on using CoAP's REST-based resource 114 retrieval and manipulation for this purpose, while changes in end 115 point identification and the transport protocol can be addressed by a 116 transport-specific messaging sublayer. This simplifies development 117 and memory requirements. Resource representations are also visible 118 in an end-to-end manner for any CoAP client. In certain conditions, 119 the processing and computational overhead for conveying CoAP Requests 120 and Responses from one underlying transport to another, would be less 121 than that of an application-level gateway performing protocol 122 translation of individual messages between CoAP and another resource 123 retrieval protocol such as HTTP. 125 This document first provides scenarios where usage of CoAP over 126 alternative transports is either currently underway, or may prove 127 advantageous in the future. A simple transport type classification 128 for CoAP-capable nodes is provided next. Then a new URI format is 129 described through which a CoAP resource representation can be 130 formulated that expresses transport identification in addition to 131 endpoint information and resource paths. Following that, a 132 discussion of the various transport properties which influence how 133 CoAP Request and Response messages are mapped to transport level 134 payloads, is presented. 136 This document however, does not touch on application QoS 137 requirements, user policies or network adaptation, nor does it 138 advocate replacing the current practice of UDP-based CoAP 139 communication. 141 2. Usage Cases 143 Apart from UDP and DTLS, CoAP usage is being specified for the 144 following environments as of this writing: 146 2.1. Use of SMS 148 CoAP messages can be sent via SMS between CoAP end-points in a 149 cellular network [I-D.becker-core-coap-sms-gprs]. A CoAP Request 150 message can also be sent via SMS from a CoAP client to a sleeping 151 CoAP Server as a wake-up mechanism and trigger communication via IP. 152 For this reason, the Open Mobile Alliance (OMA) specifies both UDP 153 and SMS as transports for M2M communication in cellular networks. 154 The OMA Lightweight M2M (LWM2M) protocol being drafted uses CoAP, and 155 as transports, specifies both UDP as well as Short Message Service 156 (SMS) bindings [OMALWM2M]. DTLS is being proposed for securing CoAP 157 messages over SMS between Mobile Stations 158 [I-D.fossati-dtls-over-gsm-sms]. 160 2.2. Use of WebSockets 162 The WebSocket protocol has been proposed as a transport channel 163 between WebSocket enabled CoAP end-points on the Internet 164 [I-D.savolainen-core-coap-websockets]. This is particularly useful 165 to enable CoAP communication within HTML5 apps and web browsers, 166 especially in smart devices, that do not have any means to use low- 167 level socket interfaces. Embedded client side scripts create new 168 WebSocket connections to various WebSocket-enabled servers, through 169 which CoAP messages can be exchanged. This also allows a browser 170 containing an embedded CoAP server to open a connection to a 171 WebSocket enabled CoAP Mirror Server [I-D.vial-core-mirror-server] to 172 register and update its resources. 174 2.3. Use of P2P Overlays 176 [I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can use a 177 peer-to-peer overlay network called RELOAD, as a resource caching 178 facility for storing wireless sensor data. When a CoAP node 179 registers its resources with a RELOAD Proxy Node (PN), the node 180 computes a hash value from the CoAP URI and stores it as a structure 181 together with the PN's Node ID as well as the resources. Resource 182 retrieval by CoAP nodes is accomplished by computing the hash key 183 over the Request URI, opening a connection to the overlay and using 184 its message routing system to contact the CoAP server via its PN. 186 2.4. Use of TCP and TLS 188 Using TCP [I-D.tschofenig-core-coap-tcp-tls], allows easier 189 communication between CoAP clients and servers separated by firewalls 190 and NATs. This also allows CoAP messages to be transported over push 191 notification services from a notification server to a client app on a 192 smartphone, that may previously have subscribed to receive change 193 notifications of CoAP resource representations, possibly by using 194 CoAP Observe [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 3. Node Types based on Transport Availability 200 The term "alternative transport" in this document thus far has been 201 used to refer to any non-UDP and non-DTLS transport that can convey 202 CoAP messages in its payload. A node however, may in fact possess 203 the capability to utilise CoAP over multiple transport channels at 204 its disposal, simultaneously or otherwise, at any point in time to 205 communicate with a CoAP end-point. Such communication can obviously 206 take place over UDP and DTLS as well. Inevitably, if two CoAP 207 endpoints reside in distinctly separate networks with orthogonal 208 transports, a CoAP proxy node is needed between the two networks so 209 that CoAP Requests and Responses can be exchanged properly. 211 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 212 devices, in terms of their resource constraints, energy limitations 213 and communication power. For this document, in addition to these 214 capabilities, it seems useful to additionally identify devices based 215 on their transport capabilities. 217 +-------+----------------------------+ 218 | Name | Transport Availability | 219 +-------+----------------------------+ 220 | T0 | Single transport | 221 | | | 222 | T1 | Multiple transports, with | 223 | | one or more active at any | 224 | | point in time | 225 | | | 226 | T2 | Multiple active transports| 227 | | at all times | 228 +-------+----------------------------+ 230 Table 1: Classes of Available Transports 232 Type T0 nodespossess the capability of exactly 1 type of transport 233 channel for CoAP, at all times. These include both active and sleepy 234 nodes, which may choose to perform duty cycling for power saving. 236 Type T1 nodes possess multiple different transports, and can retrieve 237 or expose CoAP resources over any or all of these transports. 238 However, not all transports are constantly active and certain 239 transport channels and interfaces could be kept in a mostly-off state 240 for energy-efficiency, such as when using CoAP over SMS (refer to 241 section 2.1) 243 Type T2 nodes possess more than 1 transport, and multiple transports 244 are simultaneously active at all times. CoAP proxy nodes which allow 245 CoAP endpoints from disparate transports to communicate with each 246 other, are a good example of this. 248 4. CoAP Alternative Transport URI 250 Based on the usage scenarios as well as the transport classes 251 presented in the preceding sections, this section discusses the 252 formulation of a new URI format for representing CoAP resources over 253 alternative transports. 255 CoAP is logically divided into 2 sublayers, whereby the upper layer 256 is responsible for the protocol functionality of exchanging request 257 and response messages, while the messaging layer is bound to UDP. 258 These 2 sublayers are tightly coupled, both being responsible for 259 properly encoding the header and body of the CoAP message. The CoAP 260 URI is used by both logical sublayers. For a URI that is expressed 261 generically as 263 URI = scheme ":" "//" authority path-abempty ["?" query ] 265 a simple example CoAP URI, "coap://server.example.com/sensors/ 266 temperature" is interpreted as follows: 268 coap :// server.example.com /sensors/temperature 269 \___/ \______ ________/ \______ _________/ 270 | \/ \/ 271 protocol endpoint parameterised 272 identifier identifier resource 273 identifier 275 Figure 1: The CoAP URI format 277 The resource path is explicitly expressed, and the endpoint 278 identifier, which contains the host address at the network-level is 279 also directly bound to the scheme name containing the application- 280 level protocol identifier. The choice of a specific transport for a 281 scheme, however, cannot be embedded with a URI, but is defined by 282 convention or standardisation of the protocol using the scheme. As 283 examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol 284 over TCP, while [RFC2818] requires that the 'https' protocol 285 identifier be used to differentiate using HTTP over TLS instead of 286 TCP. 288 4.1. Design Considerations 290 Several ways of formulating a URI which express an alternative 291 transport binding to CoAP, can be envisioned. When such a URI is 292 provided from an application to its CoAP implementation, the URI 293 component containing transport-specific information can be checked to 294 allow CoAP to use the appropriate transport for a target endpoint 295 identifier. 297 The following design considerations influence the formulation of a 298 new URI expressing CoAP resources over alternative transports: 300 1. The CoAP Transport URI must conform to the generic syntax for a 301 URI described in [RFC3986]. By ensuring conformance to RFC3986, 302 the need for custom URI parsers as well as resolution algorithms 303 can be obviated. In particular, a URI format needs to be 304 described in which each URI component clearly meets the syntax 305 and percent-encoding rules described. 307 2. A CoAP Transport URI can be supplied as a Proxy-Uri option by a 308 CoAP end-point to a CoAP forward proxy. This allows 309 communication with a CoAP end-point residing in a network using a 310 different transport. Section 6.4 of [RFC7252] provides an 311 algorithm for parsing a received URI to obtain the request's 312 options. Conformance to [RFC3986] is also necessary in order for 313 the parsing algorithm to be successful. 315 3. Request messages sent to a CoAP endpoint using a CoAP Transport 316 URI may be responded to with a relative URI reference, for 317 example, of the form "../../path/to/resource". In such cases, 318 the requesting endpoint needs to resolve the relative reference 319 against the original CoAP Transport URI to then obtain a new 320 target URI to which a request can be sent to, to obtain a 321 resource representation. [RFC3986] provides an algorithm to 322 establish how relative references can be resolved against a base 323 URI to obtain a target URI. Given this algorithm, a URI format 324 needs to be described in which relative reference resolution does 325 not result in a target URI that loses its transport-specific 326 information 328 4. The host component of current CoAP URIs can either be an IPv4 329 address, an IPv6 address or a resolvable hostname. While the 330 usage of DNS can sometimes be useful for distinguishing transport 331 information (see section 4.3.1), accessing DNS over some 332 alternative transport environments may be challenging. 333 Therefore, a URI format needs to be described which is able to 334 represent a resource without heavy reliance on a naming 335 infrastructure, such as DNS. 337 4.2. URI format 339 To meet the design considerations previously discussed, the transport 340 information is expressed as part of the URI scheme component. This 341 is performed by minting new schemes for alternative transports using 342 the form "coap+" and/or "coaps+", 343 where the name of the transport is clearly and unambiguously 344 described. Each scheme name formed in this manner is used to 345 differentiate the use of CoAP, or CoAP using DTLS, over an 346 alternative transport respectively. The endpoint identifier, path 347 and query components together with each scheme name would be used to 348 uniquely identify each resource. 350 Examples of such URIs are: 352 o coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP 353 over TCP 355 o coap+tls://[2001:db8::1]:5683/sensors/temperature for using CoAP 356 over TLS 358 o coaps+sctp://[2001:db8::1]:5683/sensors/temperature for using CoAP 359 over DTLS over SCTP 361 o coap+sms://0015105550101/sensors/temperature for using CoAP over 362 SMS with the endpoint identifier being a telephone subscriber 363 number 365 o coaps+sms://0015105550101/sensors/temperature for using CoAP over 366 DTLS over SMS with the endpoint identifier being a telephone 367 subscriber number 369 o coap+ws://www.example.com/sensors/temperature for using CoAP over 370 WebSockets 372 o coap+wss://www.example.com/sensors/temperature for using CoAP over 373 secure WebSockets (WebSockets using TLS) 375 A URI of this format to distinguish transport types is simple to 376 understand and not dissimilar to the CoAP URI format. As the usage 377 of each alternative transport results in an entirely new scheme, IANA 378 intervention is required for the registration of each scheme name. 379 The registration process follows the guidelines stipulated in 380 [I-D.ietf-appsawg-uri-scheme-reg], particularly where permanent URI 381 scheme registration is concerned. CoAP resources transported over 382 UDP or DTLS must conform to Section 6 of [RFC7252] and utilise "coap" 383 or "coaps" for the URI scheme, instead of "coap+udp" or "coap+dtls". 385 It is also entirely possible for each new scheme to specify its own 386 rules for how resource and transport endpoint information can be 387 presented. However, the URIs and resource representations arising 388 from their usage should meet the URI design considerations and 389 guidelines mentioned in Section 4.1. In addition, each new transport 390 being defined should take into consideration the various transport- 391 level properties that can have an impact on how CoAP messages are 392 conveyed as payload. This is elaborated on in the next section. 394 5. Alternative Transport Analysis and Properties 396 In this section the various characteristics of alternative transports 397 for successfully supporting various kinds of functionality for CoAP 398 are considered. CoAP factors lossiness, unreliability, small packet 399 sizes and connection statelessness into its protocol logic. General 400 transport differences and their impact on carrying CoAP messages here 401 are discussed. 403 Property 1: 1:N communication support. 405 This refers to the ability of the transport protocol to support 406 broadcast and multicast communication. For example, group 407 communication for CoAP is based on multicasting Request messages and 408 receiving Response messages via unicast [RFC7390]. A protocol such 409 as TCP would be ill-suited for group communications using multicast. 410 Anycast support, where a message is sent to a well defined 411 destination address to which several nodes belong, on the other hand, 412 is supported by TCP. 414 Property 2: Transport-level reliability. 416 This refers to the ability of the transport protocol to support 417 properties such as guaranteeing reliability against packet loss, 418 ensuring ordered packet delivery and having error control. When CoAP 419 Request and Response messages are delivered over such transports, the 420 CoAP implementations elide certain fields in the packet header. As 421 an example, if the usage of a connection-oriented transport renders 422 it unnecessary to specify the various CoAP message types, the Type 423 field can be elided. For some connection-oriented transports, such 424 as WebSockets, the version of CoAP being used can be negotiated 425 during the opening transfer. Consequently, the Version field in CoAP 426 packets can also be elided. 428 Property 3: Message encoding. 430 While parts of the CoAP payload are human readable or are transmitted 431 in XML, JSON or SenML format, CoAP is essentially a low overhead 432 binary protocol. Efficient transmission of such packets would 433 therefore be met with a transport offering binary encoding support. 434 Techniques exist in allowing binary payloads to be transferred over 435 text-based transport protocols such as base-64 encoding. When using 436 SMS as a transport, for example, although binary encoding is 437 supported, Appendix A.5 of [I-D.bormann-coap-misc] indicates binary 438 encoding for SMS may not always be viable. A fuller discussion about 439 performing CoAP message encoding for SMS can be found in Appendix A.5 440 of [I-D.bormann-coap-misc] 442 Property 4: Network byte order. 444 CoAP, as well as transports based on the IP stack use a Big Endian 445 byte order for transmitting packets over the air or wire, while 446 transports based on Bluetooth and Zigbee prefer Little Endian byte 447 ordering for packet fields and transmission. Any CoAP implementation 448 that potentially uses multiple transports has to ensure correct byte 449 ordering for the transport used. 451 Property 5: MTU correlation with CoAP PDU size. 453 Section 4.6 of [RFC7252] discusses the avoidance of IP fragmentation 454 by ensuring CoAP message fit into a single UDP datagram. End-points 455 on constrained networks using 6LoWPAN may use blockwise transfers to 456 accommodate even smaller packet sizes to avoid fragmentation. The 457 MTU sizes for Bluetooth Low Energy as well as Classic Bluetooth are 458 provided in Section 2.4 of [I-D.ietf-6lo-btle]. Transport MTU 459 correlation with CoAP messages helps ensure minimal to no 460 fragmentation at the transport layer. On the other hand, allowing a 461 CoAP message to be delivered using a delay-tolerant transport service 462 such as the Bundle Protocol [RFC5050] would imply that the CoAP 463 message may be fragmented (or reconstituted) along various nodes in 464 the DTN as various sized bundles and bundle fragments. 466 Property 6: Framing 467 When using CoAP over a streaming transport protocol such as TCP, as 468 opposed to datagram based protocols, care must be observed in 469 preserving message boundaries. Commonly applied techniques at the 470 transport level include the use of delimiting characters for this 471 purpose as well as message framing and length prefixing. 473 Property 7: Transport latency. 475 A confirmable CoAP request would be retransmitted by a CoAP end-point 476 if a response is not obtained within a certain time. A CoAP end- 477 point registering to a Resource Directory uses a POST message that 478 could include a lifetime value. A sleepy end-point similarly uses a 479 lifetime value to indicate the freshness of the data to a CoAP Mirror 480 Server. Care needs to be exercised to ensure the latency of the 481 transport being used to carry CoAP messages is small enough not to 482 interfere with these values for the proper operation of these 483 functionalities. 485 Property 8: Connection Management. 487 A CoAP endpoint using a connection-oriented transport should be 488 responsible for proper connection establishment prior to sending a 489 CoAP Request message. Both communicating endpoints may monitor the 490 connection health during the Data Transfer phase. Finally, once data 491 transfer is complete, at least one end point should perform 492 connection teardown gracefully. 494 6. IANA Considerations 496 This memo includes no request to IANA. 498 7. Security Considerations 500 New security risks are not envisaged to arise from the guidelines 501 given in this document, for describing a new URI format containing 502 transport identification within the URI scheme component. However, 503 when specific alternative transports are selected for implementing 504 support for carrying CoAP messages, risk factors or vulnerabilities 505 can be present. Examples include privacy trade-offs when MAC 506 addresses or phone numbers are supplied as URI authority components, 507 or if specific URI path components employed for security-specific 508 interpretations are accidentally encountered as false positives. 509 While this document does not make it mandatory to introduce a 510 security mode with each transport, it recommends ascribing meaning to 511 the use of "coap+" and "coaps+" prefixes in the scheme component, 512 with the "coaps+" prefix used for DTLS-based CoAP messages over the 513 alternative transport. 515 8. Acknowledgements 517 The draft has benefited greatly from reviews, comments and ideas from 518 Thomas Fossati, Akbar Rahman, Klaus Hartke, Martin Thomson, Mark 519 Nottingham, Dave Thaler, Graham Klyne, Carsten Bormann and Markus 520 Becker. 522 9. References 524 9.1. Normative References 526 [I-D.ietf-appsawg-uri-scheme-reg] 527 Thaler, D., Hansen, T., Hardie, T., and L. Masinter, 528 "Guidelines and Registration Procedures for URI Schemes", 529 draft-ietf-appsawg-uri-scheme-reg-06 (work in progress), 530 April 2015. 532 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 533 Resource Identifier (URI): Generic Syntax", STD 66, RFC 534 3986, January 2005. 536 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 537 Constrained-Node Networks", RFC 7228, May 2014. 539 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 540 Application Protocol (CoAP)", RFC 7252, June 2014. 542 9.2. Informative References 544 [BTCorev4.1] 545 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 546 Version 4.1", December 2013. 548 [I-D.becker-core-coap-sms-gprs] 549 Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, 550 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 551 gprs-05 (work in progress), August 2014. 553 [I-D.bormann-coap-misc] 554 Bormann, C. and K. Hartke, "Miscellaneous additions to 555 CoAP", draft-bormann-coap-misc-27 (work in progress), 556 November 2014. 558 [I-D.fossati-dtls-over-gsm-sms] 559 Fossati, T. and H. Tschofenig, "Datagram Transport Layer 560 Security (DTLS) over Global System for Mobile 561 Communications (GSM) Short Message Service (SMS)", draft- 562 fossati-dtls-over-gsm-sms-01 (work in progress), October 563 2014. 565 [I-D.ietf-6lo-btle] 566 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 567 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 568 Energy", draft-ietf-6lo-btle-13 (work in progress), May 569 2015. 571 [I-D.ietf-core-observe] 572 Hartke, K., "Observing Resources in CoAP", draft-ietf- 573 core-observe-16 (work in progress), December 2014. 575 [I-D.jimenez-p2psip-coap-reload] 576 Jimenez, J., Lopez-Vega, J., Maenpaa, J., and G. 577 Camarillo, "A Constrained Application Protocol (CoAP) 578 Usage for REsource LOcation And Discovery (RELOAD)", 579 draft-jimenez-p2psip-coap-reload-09 (work in progress), 580 June 2015. 582 [I-D.savolainen-core-coap-websockets] 583 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 584 WebSockets", draft-savolainen-core-coap-websockets-04 585 (work in progress), March 2015. 587 [I-D.tschofenig-core-coap-tcp-tls] 588 Bormann, C., Lemay, S., Technologies, Z., and H. 589 Tschofenig, "A TCP and TLS Transport for the Constrained 590 Application Protocol (CoAP)", draft-tschofenig-core-coap- 591 tcp-tls-04 (work in progress), June 2015. 593 [I-D.vial-core-mirror-server] 594 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 595 server-01 (work in progress), April 2013. 597 [OMALWM2M] 598 Open Mobile Alliance (OMA), "Lightweight Machine to 599 Machine Technical Specification Version 1.0", 2015. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 605 and Service: Schemes", RFC 2609, June 1999. 607 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 609 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 610 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 611 Networking Architecture", RFC 4838, April 2007. 613 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 614 Specification", RFC 5050, November 2007. 616 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 617 November 2007. 619 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 620 6455, December 2011. 622 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 623 Application Spaces for IPv6 over Low-Power Wireless 624 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 626 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 627 "Diameter Base Protocol", RFC 6733, October 2012. 629 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 630 Constrained Application Protocol (CoAP)", RFC 7390, 631 October 2014. 633 [WWWArchv1] 634 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 635 of the World Wide Web, Volume One", December 2004. 637 Appendix A. Expressing transport in the URI in other ways 639 Other means of indicating the transport as a distinguishable 640 component within the CoAP URI are possible, but have been deemed 641 unsuitable by not meeting the design considerations listed, or are 642 incompatible with existing practices outlined in [RFC7252]. They are 643 however, retained in this section for historical documentation and 644 completeness. 646 A.1. Transport information as part of the URI authority 648 A single URI scheme, "coap-at" can be introduced, as part of an 649 absolute URI which expresses the transport information within the 650 authority component. One approach is to structure the component with 651 a transport prefix to the endpoint identifier and a delimiter, such 652 as "-endpoint_identifier". 654 Examples of resulting URIs are: 656 o coap-at://tcp-server.example.com/sensors/temperature 658 o coap-at://sms-0015105550101/sensors/temperature 660 An implementation note here is that some generic URI parsers will 661 fail when encountering a URI such as "coap-at://tcp- 662 [2001:db8::1]/sensors/temperature". Consequently, an equivalent, but 663 parseable URI from the ip6.arpa domain needs to be formulated 664 instead. For [2001:db8::1] using TCP, this would result in the 665 following URL: 667 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 668 .1.0.0.2.ip6.arpa:5683/sensors/temperature 670 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 671 similarly be expressed with a URI from the ip6.arpa domain. 673 This URI format allows the usage of a single scheme to represent 674 multiple types of transport end-points. Consequently, it requires 675 consistency in ensuring how various transport-specific endpoints are 676 identified, as a single URI format is used. Attention must be paid 677 towards the syntax rules and encoding for the URI host component. 678 Additionally, against a base URI of the form "coap-at://tcp- 679 server.example.com/sensors/temperature", resolving a relative 680 reference, such as "//example.net/sensors/temperature" would result 681 in the target URI "coap-at://example.net/sensors/temperature", in 682 which transport information is lost. 684 A.1.1. Usage of DNS records 686 DNS names can be used instead of IPv6 address literals to mitigate 687 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 688 possible. 690 DNS SRV records can also be employed to formulate a URL such as: 692 coap-at://srv-_coap._tcp.example.com/sensors/temperature 694 in which the "srv" prefix is used to indicate that a DNS SRV lookup 695 should be used for _coap._tcp.example.com, where usage of CoAP over 696 TCP is specified for example.com, and is eventually resolved to a 697 numerical IPv4 or IPv6 address. 699 A.2. Making CoAP Resources Available over Multiple Transports 701 The CoAP URI used thus far is as follows: 703 URI = scheme ":" hier-part [ "?" query ] 704 hier-part = "//" authority path-abempty 706 A new URI format could be introduced, that does not possess an 707 "authority" component, and instead defining "hier-part" to instead 708 use another component, "path-rootless", as specified by RFC3986 709 [RFC3986]. The partial ABNF format of this URI would then be: 711 URI = scheme ":" hier-part [ "?" query ] 712 hier-part = path-rootless 713 path-rootless = segment-nz *( "/" segment ) 715 The full syntax of "path-rootless" is described in [RFC3986]. A 716 generic URI defined this way would conform to the syntax of 717 [RFC3986], while the path component can be treated as an opaque 718 string to indicate transport types, endpoints as well as paths to 719 CoAP resources. A single scheme can similarly be used. 721 A constrained node that is capable of communicating over several 722 types of transports (such as UDP, TCP and SMS) would be able to 723 convey a single CoAP resource over multiple transports. This is also 724 beneficial for nodes performing caching and proxying from one type of 725 transport to another. 727 Requesting and retrieving the same CoAP resource representation over 728 multiple transports could be rendered possible by prefixing the 729 transport type and endpoint identifier information to the CoAP URI. 730 This would result in the following example representation: 732 coap-at:tcp://example.com?coap://example.com/sensors/temperature 733 \_______ ______/ \________________ __________________/ 734 \/ \/ 735 Transport-specific CoAP Resource 736 Prefix 738 Figure 2: Prefixing a CoAP URI with TCP transport 740 Such a representation would result in the URI being decomposed into 741 its constituent components, with the CoAP resource residing within 742 the query component as follows: 744 Scheme: coap-at 746 Path: tcp://example.com 748 Query: coap://example.com/sensors/temperature 750 The same CoAP resource, if requested over a WebSocket transport, 751 would result the following URI: 753 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 754 \___________ __________/ \_______________ ___________________/ 755 \/ \/ 756 Transport-specific CoAP Resource 757 Prefix 759 Figure 3: Prefixing a CoAP URI with WebSocket transport 761 While the transport prefix changes, the CoAP resource representation 762 remains the same in the query component: 764 Scheme: coap-at 766 Path: ws://example.com/endpoint 768 Query: coap://example.com/sensors/temperature 770 The URI format described here overcomes URI aliasing [WWWArchv1] when 771 multiple transports are used, by ensuring each CoAP resource 772 representation remains the same, but is prefixed with different 773 transports. However, against a base URI of this format, resolving 774 relative references of the form "//example.net/sensors/temperature" 775 and "/sensor2/temperature" would again result in target URIs which 776 lose transport-specific information. 778 Implementation note: While square brackets are disallowed within the 779 path component, the '[' and ']' characters needed to enclose a 780 literal IPv6 address can be percent-encoded into their respective 781 equivalents. The ':' character does not need to be percent-encoded. 782 This results in a significantly simpler URI string compared to 783 section 2.2, particularly for compressed IPv6 addresses. 784 Additionally, the URI format can be used to specify other similar 785 address families and formats, such as Bluetooth addresses 786 [BTCorev4.1]. 788 A.3. Transport as part of a 'service:' URL scheme 790 The "service:" URL scheme name was introduced in [RFC2609] and forms 791 the basis of service description used primarily by the Service 792 Location Protocol. An abstract service type URI would have the form 794 "service::" 796 where refers to a service type name that can be 797 associated with a variety of protocols, while the 798 then providing the specific details of the protocol used, authority 799 and other URI components. 801 Adopting the "service:" URL scheme to describe CoAP usage over 802 alternative transports would be rather trivial. To use a previous 803 example, a CoAP service to discover a Resource Directory and its base 804 RD resource using TCP would take the form 806 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 808 The syntax of the "service:" URL scheme differs from the generic URI 809 syntax and therefore such a representation should be treated as an 810 opaque URI as Section 2.1 of [RFC2609] recommends. 812 Authors' Addresses 814 Bilhanan Silverajan 815 Tampere University of Technology 816 Korkeakoulunkatu 10 817 FI-33720 Tampere 818 Finland 820 Email: bilhanan.silverajan@tut.fi 822 Teemu Savolainen 823 Nokia 824 Hermiankatu 12 D 825 FI-33720 Tampere 826 Finland 828 Email: teemu.savolainen@nokia.com