idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-09.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 271 has weird spacing: '...ntifier ide...' -- The document date (December 21, 2015) is 3043 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC4838' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 631, 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 (-11) exists of draft-ietf-core-coap-tcp-tls-01 == Outdated reference: A later version (-07) exists of draft-savolainen-core-coap-websockets-05 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 10 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 23, 2016 Nokia 6 December 21, 2015 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-09 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 June 23, 2016. 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 . . . 15 79 A.1. Transport information as part of the URI authority . . . 15 80 A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 16 81 A.2. Making CoAP Resources Available over Multiple Transports 16 82 A.3. Transport as part of a 'service:' URL scheme . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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.ietf-core-coap-tcp-tls], allows easier communication 189 between CoAP clients and servers separated by firewalls and NATs. 190 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 [RFC7641]. [I-D.ietf-core-coap-tcp-tls] also discusses 195 using TLS as a transport to securely convey CoAP messages over TCP. 197 3. Node Types based on Transport Availability 199 The term "alternative transport" in this document thus far has been 200 used to refer to any non-UDP and non-DTLS transport that can convey 201 CoAP messages in its payload. A node however, may in fact possess 202 the capability to utilise CoAP over multiple transport channels at 203 its disposal, simultaneously or otherwise, at any point in time to 204 communicate with a CoAP end-point. Such communication can obviously 205 take place over UDP and DTLS as well. Inevitably, if two CoAP 206 endpoints reside in distinctly separate networks with orthogonal 207 transports, a CoAP proxy node is needed between the two networks so 208 that CoAP Requests and Responses can be exchanged properly. 210 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 211 devices, in terms of their resource constraints, energy limitations 212 and communication power. For this document, in addition to these 213 capabilities, it seems useful to additionally identify devices based 214 on their transport capabilities. 216 +-------+----------------------------+ 217 | Name | Transport Availability | 218 +-------+----------------------------+ 219 | T0 | Single transport | 220 | | | 221 | T1 | Multiple transports, with | 222 | | one or more active at any | 223 | | point in time | 224 | | | 225 | T2 | Multiple active transports| 226 | | at all times | 227 +-------+----------------------------+ 229 Table 1: Classes of Available Transports 231 Type T0 nodespossess the capability of exactly 1 type of transport 232 channel for CoAP, at all times. These include both active and sleepy 233 nodes, which may choose to perform duty cycling for power saving. 235 Type T1 nodes possess multiple different transports, and can retrieve 236 or expose CoAP resources over any or all of these transports. 237 However, not all transports are constantly active and certain 238 transport channels and interfaces could be kept in a mostly-off state 239 for energy-efficiency, such as when using CoAP over SMS (refer to 240 section 2.1) 242 Type T2 nodes possess more than 1 transport, and multiple transports 243 are simultaneously active at all times. CoAP proxy nodes which allow 244 CoAP endpoints from disparate transports to communicate with each 245 other, are a good example of this. 247 4. CoAP Alternative Transport URI 249 Based on the usage scenarios as well as the transport classes 250 presented in the preceding sections, this section discusses the 251 formulation of a new URI format for representing CoAP resources over 252 alternative transports. 254 CoAP is logically divided into 2 sublayers, whereby the upper layer 255 is responsible for the protocol functionality of exchanging request 256 and response messages, while the messaging layer is bound to UDP. 257 These 2 sublayers are tightly coupled, both being responsible for 258 properly encoding the header and body of the CoAP message. The CoAP 259 URI is used by both logical sublayers. For a URI that is expressed 260 generically as 262 URI = scheme ":" "//" authority path-abempty ["?" query ] 264 a simple example CoAP URI, "coap://server.example.com/sensors/ 265 temperature" is interpreted as follows: 267 coap :// server.example.com /sensors/temperature 268 \___/ \______ ________/ \______ _________/ 269 | \/ \/ 270 protocol endpoint parameterised 271 identifier identifier resource 272 identifier 274 Figure 1: The CoAP URI format 276 The resource path is explicitly expressed, and the endpoint 277 identifier, which contains the host address at the network-level is 278 also directly bound to the scheme name containing the application- 279 level protocol identifier. The choice of a specific transport for a 280 scheme, however, cannot be embedded with a URI, but is defined by 281 convention or standardisation of the protocol using the scheme. As 282 examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol 283 over TCP, while [RFC2818] requires that the 'https' protocol 284 identifier be used to differentiate using HTTP over TLS instead of 285 TCP. 287 4.1. Design Considerations 289 Several ways of formulating a URI which express an alternative 290 transport binding to CoAP, can be envisioned. When such a URI is 291 provided from an application to its CoAP implementation, the URI 292 component containing transport-specific information can be checked to 293 allow CoAP to use the appropriate transport for a target endpoint 294 identifier. 296 The following design considerations influence the formulation of a 297 new URI expressing CoAP resources over alternative transports: 299 1. The CoAP Transport URI must conform to the generic syntax for a 300 URI described in [RFC3986]. By ensuring conformance to RFC3986, 301 the need for custom URI parsers as well as resolution algorithms 302 can be obviated. In particular, a URI format needs to be 303 described in which each URI component clearly meets the syntax 304 and percent-encoding rules described. 306 2. A CoAP Transport URI can be supplied as a Proxy-Uri option by a 307 CoAP end-point to a CoAP forward proxy. This allows 308 communication with a CoAP end-point residing in a network using a 309 different transport. Section 6.4 of [RFC7252] provides an 310 algorithm for parsing a received URI to obtain the request's 311 options. Conformance to [RFC3986] is also necessary in order for 312 the parsing algorithm to be successful. 314 3. Request messages sent to a CoAP endpoint using a CoAP Transport 315 URI may be responded to with a relative URI reference, for 316 example, of the form "../../path/to/resource". In such cases, 317 the requesting endpoint needs to resolve the relative reference 318 against the original CoAP Transport URI to then obtain a new 319 target URI to which a request can be sent to, to obtain a 320 resource representation. [RFC3986] provides an algorithm to 321 establish how relative references can be resolved against a base 322 URI to obtain a target URI. Given this algorithm, a URI format 323 needs to be described in which relative reference resolution does 324 not result in a target URI that loses its transport-specific 325 information 327 4. The host component of current CoAP URIs can either be an IPv4 328 address, an IPv6 address or a resolvable hostname. While the 329 usage of DNS can sometimes be useful for distinguishing transport 330 information (see section 4.3.1), accessing DNS over some 331 alternative transport environments may be challenging. 332 Therefore, a URI format needs to be described which is able to 333 represent a resource without heavy reliance on a naming 334 infrastructure, such as DNS. 336 4.2. URI format 338 To meet the design considerations previously discussed, the transport 339 information is expressed as part of the URI scheme component. This 340 is performed by minting new schemes for alternative transports using 341 the form "coap+" and/or "coaps+", 342 where the name of the transport is clearly and unambiguously 343 described. Each scheme name formed in this manner is used to 344 differentiate the use of CoAP, or CoAP using DTLS, over an 345 alternative transport respectively. The endpoint identifier, path 346 and query components together with each scheme name would be used to 347 uniquely identify each resource. 349 Examples of such URIs are: 351 o coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP 352 over TCP 354 o coap+tls://[2001:db8::1]:5683/sensors/temperature for using CoAP 355 over TLS 357 o coaps+sctp://[2001:db8::1]:5683/sensors/temperature for using CoAP 358 over DTLS over SCTP 360 o coap+sms://0015105550101/sensors/temperature for using CoAP over 361 SMS with the endpoint identifier being a telephone subscriber 362 number 364 o coaps+sms://0015105550101/sensors/temperature for using CoAP over 365 DTLS over SMS with the endpoint identifier being a telephone 366 subscriber number 368 o coap+ws://www.example.com/sensors/temperature for using CoAP over 369 WebSockets 371 o coap+wss://www.example.com/sensors/temperature for using CoAP over 372 secure WebSockets (WebSockets using TLS) 374 A URI of this format to distinguish transport types is simple to 375 understand and not dissimilar to the CoAP URI format. As the usage 376 of each alternative transport results in an entirely new scheme, IANA 377 intervention is required for the registration of each scheme name. 378 The registration process follows the guidelines stipulated in 379 [I-D.ietf-appsawg-uri-scheme-reg], particularly where permanent URI 380 scheme registration is concerned. CoAP resources transported over 381 UDP or DTLS must conform to Section 6 of [RFC7252] and utilise "coap" 382 or "coaps" for the URI scheme, instead of "coap+udp" or "coap+dtls". 384 It is also entirely possible for each new scheme to specify its own 385 rules for how resource and transport endpoint information can be 386 presented. However, the URIs and resource representations arising 387 from their usage should meet the URI design considerations and 388 guidelines mentioned in Section 4.1. In addition, each new transport 389 being defined should take into consideration the various transport- 390 level properties that can have an impact on how CoAP messages are 391 conveyed as payload. This is elaborated on in the next section. 393 5. Alternative Transport Analysis and Properties 395 In this section the various characteristics of alternative transports 396 for successfully supporting various kinds of functionality for CoAP 397 are considered. CoAP factors lossiness, unreliability, small packet 398 sizes and connection statelessness into its protocol logic. General 399 transport differences and their impact on carrying CoAP messages here 400 are discussed. 402 Property 1: 1:N communication support. 404 This refers to the ability of the transport protocol to support 405 broadcast and multicast communication. For example, group 406 communication for CoAP is based on multicasting Request messages and 407 receiving Response messages via unicast [RFC7390]. A protocol such 408 as TCP would be ill-suited for group communications using multicast. 409 Anycast support, where a message is sent to a well defined 410 destination address to which several nodes belong, on the other hand, 411 is supported by TCP. 413 Property 2: Transport-level reliability. 415 This refers to the ability of the transport protocol to support 416 properties such as guaranteeing reliability against packet loss, 417 ensuring ordered packet delivery and having error control. When CoAP 418 Request and Response messages are delivered over such transports, the 419 CoAP implementations elide certain fields in the packet header. As 420 an example, if the usage of a connection-oriented transport renders 421 it unnecessary to specify the various CoAP message types, the Type 422 field can be elided. For some connection-oriented transports, such 423 as WebSockets, the version of CoAP being used can be negotiated 424 during the opening transfer. Consequently, the Version field in CoAP 425 packets can also be elided. 427 Property 3: Message encoding. 429 While parts of the CoAP payload are human readable or are transmitted 430 in XML, JSON or SenML format, CoAP is essentially a low overhead 431 binary protocol. Efficient transmission of such packets would 432 therefore be met with a transport offering binary encoding support. 433 Techniques exist in allowing binary payloads to be transferred over 434 text-based transport protocols such as base-64 encoding. When using 435 SMS as a transport, for example, although binary encoding is 436 supported, Appendix A.5 of [I-D.bormann-coap-misc] indicates binary 437 encoding for SMS may not always be viable. A fuller discussion about 438 performing CoAP message encoding for SMS can be found in Appendix A.5 439 of [I-D.bormann-coap-misc] 441 Property 4: Network byte order. 443 CoAP, as well as transports based on the IP stack use a Big Endian 444 byte order for transmitting packets over the air or wire, while 445 transports based on Bluetooth and Zigbee prefer Little Endian byte 446 ordering for packet fields and transmission. Any CoAP implementation 447 that potentially uses multiple transports has to ensure correct byte 448 ordering for the transport used. 450 Property 5: MTU correlation with CoAP PDU size. 452 Section 4.6 of [RFC7252] discusses the avoidance of IP fragmentation 453 by ensuring CoAP message fit into a single UDP datagram. End-points 454 on constrained networks using 6LoWPAN may use blockwise transfers to 455 accommodate even smaller packet sizes to avoid fragmentation. The 456 MTU sizes for Bluetooth Low Energy as well as Classic Bluetooth are 457 provided in Section 2.4 of [RFC7668]. Transport MTU correlation with 458 CoAP messages helps ensure minimal to no fragmentation at the 459 transport layer. On the other hand, allowing a CoAP message to be 460 delivered using a delay-tolerant transport service such as the Bundle 461 Protocol [RFC5050] would imply that the CoAP message may be 462 fragmented (or reconstituted) along various nodes in the DTN as 463 various sized bundles and bundle fragments. 465 Property 6: Framing 466 When using CoAP over a streaming transport protocol such as TCP, as 467 opposed to datagram based protocols, care must be observed in 468 preserving message boundaries. Commonly applied techniques at the 469 transport level include the use of delimiting characters for this 470 purpose as well as message framing and length prefixing. 472 Property 7: Transport latency. 474 A confirmable CoAP request would be retransmitted by a CoAP end-point 475 if a response is not obtained within a certain time. A CoAP end- 476 point registering to a Resource Directory uses a POST message that 477 could include a lifetime value. A sleepy end-point similarly uses a 478 lifetime value to indicate the freshness of the data to a CoAP Mirror 479 Server. Care needs to be exercised to ensure the latency of the 480 transport being used to carry CoAP messages is small enough not to 481 interfere with these values for the proper operation of these 482 functionalities. 484 Property 8: Connection Management. 486 A CoAP endpoint using a connection-oriented transport should be 487 responsible for proper connection establishment prior to sending a 488 CoAP Request message. Both communicating endpoints may monitor the 489 connection health during the Data Transfer phase. Finally, once data 490 transfer is complete, at least one end point should perform 491 connection teardown gracefully. 493 6. IANA Considerations 495 This memo includes no request to IANA. 497 7. Security Considerations 499 New security risks are not envisaged to arise from the guidelines 500 given in this document, for describing a new URI format containing 501 transport identification within the URI scheme component. However, 502 when specific alternative transports are selected for implementing 503 support for carrying CoAP messages, risk factors or vulnerabilities 504 can be present. Examples include privacy trade-offs when MAC 505 addresses or phone numbers are supplied as URI authority components, 506 or if specific URI path components employed for security-specific 507 interpretations are accidentally encountered as false positives. 508 While this document does not make it mandatory to introduce a 509 security mode with each transport, it recommends ascribing meaning to 510 the use of "coap+" and "coaps+" prefixes in the scheme component, 511 with the "coaps+" prefix used for DTLS-based CoAP messages over the 512 alternative transport. 514 8. Acknowledgements 516 The draft has benefited greatly from reviews, comments and ideas from 517 Thomas Fossati, Akbar Rahman, Klaus Hartke, Martin Thomson, Mark 518 Nottingham, Dave Thaler, Graham Klyne, Carsten Bormann and Markus 519 Becker. 521 9. References 523 9.1. Normative References 525 [I-D.ietf-appsawg-uri-scheme-reg] 526 Thaler, D., Hansen, T., Hardie, T., and L. Masinter, 527 "Guidelines and Registration Procedures for URI Schemes", 528 draft-ietf-appsawg-uri-scheme-reg-06 (work in progress), 529 April 2015. 531 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 532 Resource Identifier (URI): Generic Syntax", STD 66, 533 RFC 3986, DOI 10.17487/RFC3986, January 2005, 534 . 536 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 537 Constrained-Node Networks", RFC 7228, 538 DOI 10.17487/RFC7228, May 2014, 539 . 541 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 542 Application Protocol (CoAP)", RFC 7252, 543 DOI 10.17487/RFC7252, June 2014, 544 . 546 9.2. Informative References 548 [BTCorev4.1] 549 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 550 Version 4.1", December 2013. 552 [I-D.becker-core-coap-sms-gprs] 553 Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, 554 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 555 gprs-05 (work in progress), August 2014. 557 [I-D.bormann-coap-misc] 558 Bormann, C. and K. Hartke, "Miscellaneous additions to 559 CoAP", draft-bormann-coap-misc-27 (work in progress), 560 November 2014. 562 [I-D.fossati-dtls-over-gsm-sms] 563 Fossati, T. and H. Tschofenig, "Datagram Transport Layer 564 Security (DTLS) over Global System for Mobile 565 Communications (GSM) Short Message Service (SMS)", draft- 566 fossati-dtls-over-gsm-sms-01 (work in progress), October 567 2014. 569 [I-D.ietf-core-coap-tcp-tls] 570 Bormann, C., Lemay, S., Technologies, Z., and H. 571 Tschofenig, "A TCP and TLS Transport for the Constrained 572 Application Protocol (CoAP)", draft-ietf-core-coap-tcp- 573 tls-01 (work in progress), November 2015. 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-10 (work in progress), 580 July 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-05 585 (work in progress), October 2015. 587 [I-D.vial-core-mirror-server] 588 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 589 server-01 (work in progress), April 2013. 591 [OMALWM2M] 592 Open Mobile Alliance (OMA), "Lightweight Machine to 593 Machine Technical Specification Version 1.0", 2015. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, 597 DOI 10.17487/RFC2119, March 1997, 598 . 600 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 601 and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609, 602 June 1999, . 604 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 605 DOI 10.17487/RFC2818, May 2000, 606 . 608 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 609 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 610 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 611 April 2007, . 613 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 614 Specification", RFC 5050, DOI 10.17487/RFC5050, November 615 2007, . 617 [RFC5092] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", 618 RFC 5092, DOI 10.17487/RFC5092, November 2007, 619 . 621 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 622 RFC 6455, DOI 10.17487/RFC6455, December 2011, 623 . 625 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 626 Application Spaces for IPv6 over Low-Power Wireless 627 Personal Area Networks (6LoWPANs)", RFC 6568, 628 DOI 10.17487/RFC6568, April 2012, 629 . 631 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 632 Ed., "Diameter Base Protocol", RFC 6733, 633 DOI 10.17487/RFC6733, October 2012, 634 . 636 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 637 the Constrained Application Protocol (CoAP)", RFC 7390, 638 DOI 10.17487/RFC7390, October 2014, 639 . 641 [RFC7641] Hartke, K., "Observing Resources in the Constrained 642 Application Protocol (CoAP)", RFC 7641, 643 DOI 10.17487/RFC7641, September 2015, 644 . 646 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 647 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 648 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 649 . 651 [WWWArchv1] 652 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 653 of the World Wide Web, Volume One", December 2004. 655 Appendix A. Expressing transport in the URI in other ways 657 Other means of indicating the transport as a distinguishable 658 component within the CoAP URI are possible, but have been deemed 659 unsuitable by not meeting the design considerations listed, or are 660 incompatible with existing practices outlined in [RFC7252]. They are 661 however, retained in this section for historical documentation and 662 completeness. 664 A.1. Transport information as part of the URI authority 666 A single URI scheme, "coap-at" can be introduced, as part of an 667 absolute URI which expresses the transport information within the 668 authority component. One approach is to structure the component with 669 a transport prefix to the endpoint identifier and a delimiter, such 670 as "-endpoint_identifier". 672 Examples of resulting URIs are: 674 o coap-at://tcp-server.example.com/sensors/temperature 676 o coap-at://sms-0015105550101/sensors/temperature 678 An implementation note here is that some generic URI parsers will 679 fail when encountering a URI such as "coap-at://tcp- 680 [2001:db8::1]/sensors/temperature". Consequently, an equivalent, but 681 parseable URI from the ip6.arpa domain needs to be formulated 682 instead. For [2001:db8::1] using TCP, this would result in the 683 following URL: 685 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 686 .1.0.0.2.ip6.arpa:5683/sensors/temperature 688 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 689 similarly be expressed with a URI from the ip6.arpa domain. 691 This URI format allows the usage of a single scheme to represent 692 multiple types of transport end-points. Consequently, it requires 693 consistency in ensuring how various transport-specific endpoints are 694 identified, as a single URI format is used. Attention must be paid 695 towards the syntax rules and encoding for the URI host component. 696 Additionally, against a base URI of the form "coap-at://tcp- 697 server.example.com/sensors/temperature", resolving a relative 698 reference, such as "//example.net/sensors/temperature" would result 699 in the target URI "coap-at://example.net/sensors/temperature", in 700 which transport information is lost. 702 A.1.1. Usage of DNS records 704 DNS names can be used instead of IPv6 address literals to mitigate 705 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 706 possible. 708 DNS SRV records can also be employed to formulate a URL such as: 710 coap-at://srv-_coap._tcp.example.com/sensors/temperature 712 in which the "srv" prefix is used to indicate that a DNS SRV lookup 713 should be used for _coap._tcp.example.com, where usage of CoAP over 714 TCP is specified for example.com, and is eventually resolved to a 715 numerical IPv4 or IPv6 address. 717 A.2. Making CoAP Resources Available over Multiple Transports 719 The CoAP URI used thus far is as follows: 721 URI = scheme ":" hier-part [ "?" query ] 722 hier-part = "//" authority path-abempty 724 A new URI format could be introduced, that does not possess an 725 "authority" component, and instead defining "hier-part" to instead 726 use another component, "path-rootless", as specified by RFC3986 727 [RFC3986]. The partial ABNF format of this URI would then be: 729 URI = scheme ":" hier-part [ "?" query ] 730 hier-part = path-rootless 731 path-rootless = segment-nz *( "/" segment ) 733 The full syntax of "path-rootless" is described in [RFC3986]. A 734 generic URI defined this way would conform to the syntax of 735 [RFC3986], while the path component can be treated as an opaque 736 string to indicate transport types, endpoints as well as paths to 737 CoAP resources. A single scheme can similarly be used. 739 A constrained node that is capable of communicating over several 740 types of transports (such as UDP, TCP and SMS) would be able to 741 convey a single CoAP resource over multiple transports. This is also 742 beneficial for nodes performing caching and proxying from one type of 743 transport to another. 745 Requesting and retrieving the same CoAP resource representation over 746 multiple transports could be rendered possible by prefixing the 747 transport type and endpoint identifier information to the CoAP URI. 748 This would result in the following example representation: 750 coap-at:tcp://example.com?coap://example.com/sensors/temperature 751 \_______ ______/ \________________ __________________/ 752 \/ \/ 753 Transport-specific CoAP Resource 754 Prefix 756 Figure 2: Prefixing a CoAP URI with TCP transport 758 Such a representation would result in the URI being decomposed into 759 its constituent components, with the CoAP resource residing within 760 the query component as follows: 762 Scheme: coap-at 764 Path: tcp://example.com 766 Query: coap://example.com/sensors/temperature 768 The same CoAP resource, if requested over a WebSocket transport, 769 would result the following URI: 771 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 772 \___________ __________/ \_______________ ___________________/ 773 \/ \/ 774 Transport-specific CoAP Resource 775 Prefix 777 Figure 3: Prefixing a CoAP URI with WebSocket transport 779 While the transport prefix changes, the CoAP resource representation 780 remains the same in the query component: 782 Scheme: coap-at 784 Path: ws://example.com/endpoint 785 Query: coap://example.com/sensors/temperature 787 The URI format described here overcomes URI aliasing [WWWArchv1] when 788 multiple transports are used, by ensuring each CoAP resource 789 representation remains the same, but is prefixed with different 790 transports. However, against a base URI of this format, resolving 791 relative references of the form "//example.net/sensors/temperature" 792 and "/sensor2/temperature" would again result in target URIs which 793 lose transport-specific information. 795 Implementation note: While square brackets are disallowed within the 796 path component, the '[' and ']' characters needed to enclose a 797 literal IPv6 address can be percent-encoded into their respective 798 equivalents. The ':' character does not need to be percent-encoded. 799 This results in a significantly simpler URI string compared to 800 section 2.2, particularly for compressed IPv6 addresses. 801 Additionally, the URI format can be used to specify other similar 802 address families and formats, such as Bluetooth addresses 803 [BTCorev4.1]. 805 A.3. Transport as part of a 'service:' URL scheme 807 The "service:" URL scheme name was introduced in [RFC2609] and forms 808 the basis of service description used primarily by the Service 809 Location Protocol. An abstract service type URI would have the form 811 "service::" 813 where refers to a service type name that can be 814 associated with a variety of protocols, while the 815 then providing the specific details of the protocol used, authority 816 and other URI components. 818 Adopting the "service:" URL scheme to describe CoAP usage over 819 alternative transports would be rather trivial. To use a previous 820 example, a CoAP service to discover a Resource Directory and its base 821 RD resource using TCP would take the form 823 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 825 The syntax of the "service:" URL scheme differs from the generic URI 826 syntax and therefore such a representation should be treated as an 827 opaque URI as Section 2.1 of [RFC2609] recommends. 829 Authors' Addresses 831 Bilhanan Silverajan 832 Tampere University of Technology 833 Korkeakoulunkatu 10 834 FI-33720 Tampere 835 Finland 837 Email: bilhanan.silverajan@tut.fi 839 Teemu Savolainen 840 Nokia 841 Hermiankatu 12 D 842 FI-33720 Tampere 843 Finland 845 Email: teemu.savolainen@nokia.com