idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-03.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 6 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 227 has weird spacing: '...ntifier ide...' -- The document date (October 21, 2013) is 3812 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA-paparazzi-uri' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC2609' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 654, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-becker-core-coap-sms-gprs-04 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-25 == Outdated reference: A later version (-01) exists of draft-bormann-core-coap-tcp-00 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-10) exists of draft-jimenez-p2psip-coap-reload-03 == Outdated reference: A later version (-07) exists of draft-savolainen-core-coap-websockets-01 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 3 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: April 24, 2014 Nokia 6 October 21, 2013 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-03 11 Abstract 13 CoAP is being standardised as an application level REST-based 14 protocol. A single CoAP message is typically encapsulated and 15 transmitted using UDP. This draft examines the requirements and 16 possible solutions for conveying CoAP packets to end points over 17 alternative transports to UDP. UDP remains the optimal solution for 18 CoAP use in IP-based constrained environments and nodes. However the 19 need for M2M communication using non-IP networks, improved transport 20 level end-to-end reliability and security, NAT and firewall traversal 21 issues, and mechanisms possibly incurring a lower overhead to CoAP/ 22 HTTP translation gateways provide compelling motivation for 23 understanding how CoAP can operate in various other environments. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Using Alternative Transports . . . . . . . . . . . . . . 3 61 1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. CoAP Transport URI . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Transport information in URI scheme . . . . . . . . . . . 6 64 2.2. Transport information as part of the URI authority . . . 7 65 2.2.1. Usage of DNS records . . . . . . . . . . . . . . . . 7 66 2.3. Transport information in URI without authority component 7 67 2.3.1. Making CoAP Resources Available over Multiple 68 Transports . . . . . . . . . . . . . . . . . . . . . 8 69 3. Alternative Transport Analysis and Properties . . . . . . . . 10 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Informative References . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is 79 being standardised by the CoRE WG as a lightweight, HTTP-like 80 protocol providing a request/response model that constrained nodes 81 can use to communicate with other nodes, be those servers, proxies, 82 gateways, less constrained nodes, or other constrained nodes. 84 As the Internet continues taking shape by integrating new kinds of 85 networks, services and devices, the need for a consistent, 86 lightweight method for resource representation, retrieval and 87 manipulation becomes evident. Owing to its simplicity and low 88 overhead, CoAP is a highly suitable protocol for this purpose. 89 However, the CoAP endpoint can reside in a non-IP network, be 90 separated from its peer by NATs and firewalls or simply has no 91 possibility to communicate over UDP. Consequently in addition to 92 UDP, alternative transport channels for conveying CoAP packets could 93 be considered. 95 This document looks at how CoAP can be used by nodes for resource 96 retrieval, in an end-to-end manner regardless of the transport 97 channel available. It looks at current usage of CoAP in this regard 98 today and provides other possible scenarios. Then the document looks 99 at how resources using CoAP can contain resource information that 100 provide endpoint as well as transport identifiers, without imposing 101 incompatibilities with [I-D.ietf-core-coap] and maintaining 102 conformance to [RFC3986]. 104 This draft does not discuss on application QoS requirements, user 105 policies or network adaptation, nor does it advocate replacing the 106 current practice of UDP-based CoAP communication. The scope of this 107 draft is limited towards a description and a requirements capture of 108 how CoAP packets can be transmitted over alternative transports, 109 especially how such protocols can be expressed at the CoAP layer, as 110 well as how CoAP packets can be mapped at transport level payloads. 112 1.1. Using Alternative Transports 114 Extending CoAP's REST-based usage over alternative transports allows 115 CoAP implementations to have a significantly larger relevance in 116 constrained as well as non-constrained networked environments. It 117 leads to better code optimisation in constrained nodes and 118 implementation reuse across new transport channels. As opposed to 119 implementing new resource retrieval schemes, an application in an 120 end-node can continue relying on using CoAP for this purpose, but 121 lets CoAP take into account the change in end point identification 122 and transport protocol. This simplifies development and memory 123 requirements. Resource representations are also visible in an end- 124 to-end manner for any CoAP client. 126 Inevitably, if two CoAP endpoints reside in distinctly separate 127 networks with orthogonal transports, a CoAP proxy node is needed 128 between the 2 networks so that CoAP Requests and Responses can be 129 fulfilled properly. The processing and computational overhead for 130 conveying CoAP packets from one underlying transport to another, 131 would be less than that of an application-level gateway performing 132 individual packet-based, protocol translation between CoAP to another 133 resource retrieval scheme. 135 1.2. Use Cases 137 CoAP has been designed to work on top of UDP, that is, on top of a 138 transport that can lose, reorder, and duplicate packets. UDP has 139 been chosen as the transport protocol over IP due its lightweight 140 nature and connectionless characteristics. In addition to point-to- 141 point communication, this allows multicast and group communications 142 [I-D.ietf-core-groupcomm]. Moreover, DTLS can be employed to secure 143 CoAP communication. 145 At this time of writing, the use of CoAP is also being specified for 146 other environments as follows: 148 1. CoAP Request and Response messages can be sent via SMS or USSD 149 between CoAP end-points in a cellular network 150 [I-D.becker-core-coap-sms-gprs]. A CoAP Request message can also 151 be sent via SMS from a CoAP client to a sleeping CoAP Server as a 152 wake-up mechanism for subsequent communication via GPRS. The 153 Open Mobile Alliance (OMA) specifies both UDP and SMS as 154 transports for M2M communication in cellular networks. The OMA 155 Lightweight M2M protocol being drafted uses CoAP, and as 156 transports, specifies both UDP binding as well as Short Message 157 Service (SMS) bindings [OMALWM2M] for the same reason. 159 2. The WebSocket protocol is being used as a transport channel 160 between WebSocket enabled CoAP end-points on the Internet 161 [I-D.savolainen-core-coap-websockets]. This is particularly 162 useful as a means for web browsers, particularly in smart 163 devices, to allow embedded client side scripts to upgrade an 164 existing HTTP connection to a WebSocket connection through which 165 CoAP Request and Response messages can be exchanged with a 166 WebSocket-enabled server. This also allows a browser containing 167 an embedded CoAP server to behave as a WebSocket client by 168 opening a connection to a WebSocket enabled CoAP Mirror Server to 169 register and update its resources. 171 3. [I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can 172 use a peer-to-peer overlay network called RELOAD, as a resource 173 caching facility for storing wireless sensor data. When a CoAP 174 node registers its resources with a RELOAD Proxy Node (PN), the 175 node computes a hash value from the CoAP URI and stores it as a 176 structure together with the PN's Node ID as well as the 177 resources. Resource retrieval by CoAP nodes is accomplished by 178 computing the hash key over the Request URI,opening a connection 179 to the overlay and using its message routing system to contact 180 the CoAP server via its PN. 182 4. Using TCP to facilitate the traversal of CoAP Request and 183 Response messages [I-D.bormann-core-coap-tcp]. This allows 184 easier communication between CoAP clients and servers separated 185 by firewalls and NATS. This also allows CoAP messages to be 186 transported over push notification services from a notification 187 server to a client app on a smartphone, that may previously have 188 subscribed to receive change notifications of CoAP resource 189 representations, possibly by using CoAP Observe-functionality 190 [I-D.ietf-core-observe]. 192 We also envisage CoAP being extended atop other transport channels, 193 such as: 195 1. The transportation of CoAP messages in Delay-Tolerant Networks 196 [RFC4838], using the Bundle Protocol [RFC5050] for reaching 197 sensors in extremely challenging environments such as acoustic, 198 underwater and deep space networks. 200 2. Any type of non-IP networks supporting constrained nodes and low- 201 energy sensors, such as Bluetooth and Bluetooth Low Energy 202 (either through L2CAP or with GATT), ZigBee, Z-Wave, 1-Wire, 203 DASH7 and so on. 205 3. Instant Messaging and Social Networking channels, such as Jabber 206 and Twitter. 208 2. CoAP Transport URI 210 CoAP is logically divided into 2 sublayers, whereby a request/ 211 response layer is responsible for the protocol functionality of 212 exchanging request and response messages, while the messaging layer 213 is bound to UDP. These 2 sublayers are tightly coupled, both being 214 responsible for properly encoding the header and body of the CoAP 215 message. The COAP URI is used by both logical sublayers. For a URI 216 that is expressed generically as 218 URI = scheme ":" "//" authority path-abempty ["?"query ] 220 A simple example COAP URI, "coap://server.example.com/sensors/ 221 temperature" can be interpreted as follows: 223 coap :// server.example.com /sensors/temperature 224 \___/ \______ ________/ \______ _________/ 225 | \/ \/ 226 protocol endpoint parameterised 227 identifier identifier resource 228 identifier 230 Figure 1: The CoAP URI format 232 The resource path is explicitly expressed, and the endpoint 233 identifier, which contains the host address at the network-level is 234 also directly bound to the scheme name containing the application- 235 level protocol identifier. The choice of a specific transport for a 236 scheme, however, cannot be embedded with a URI, but is defined by 237 convention or standardisation of the protocol using the scheme. As 238 examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol 239 over TCP, while [RFC2818] requires that the 'https' protocol 240 identifier be used to differentiate using HTTP over TLS instead of 241 TCP. 243 Several ways of formulating a URI which express an alternative 244 transport binding to CoAP, can be envisioned. These are listed in 245 this section. When such a URI is provided from an end-application to 246 its CoAP implementation, the URI component containing transport- 247 specific information can be checked to allow the CoAP to use the 248 appropriate transport for a target endpoint identifier. 250 The CoAP Transport URI can also be supplied as a Proxy-Uri option by 251 a CoAP end-point to a CoAP forward proxy in order to communicate with 252 a CoAP end-point residing in a network using a different transport. 253 Section 6.4 of [I-D.ietf-core-coap] provides an algorithm for parsing 254 a received URI to obtain the request's options. 256 2.1. Transport information in URI scheme 258 The URI scheme can follow a convention of the form "coap+", where the name of the transport is clearly and unambiguously 260 described. Each scheme name formed in this manner can be used to 261 differentiate the use of CoAP over an alternative transport instead 262 of the use of CoAP over UDP or DTLS. The endpoint identifier, path 263 and query components together with each scheme name would be used to 264 uniquely identify each resource. 266 Examples of such URIs are: 268 o coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP 269 over TCP 271 o coap+sms://0015105550101/sensors/temperature for using CoAP over 272 SMS or USSD with the endpoint identifier being a telephone 273 subscriber number 275 o coap+ws://www.example.com/WebSocket?/sensors/temperature for using 276 CoAP over WebSockets with the endpoint at ws://www.example.com/ 277 WebSocket 279 Note: Expressing target address formats other than IPv6 literal 280 addresses with '[' and ']' characters within this URI format, such as 281 Bluetooth, is as yet unresolved. 283 As the usage of each alternative transport results in an entirely new 284 scheme, IANA intervention is required for the registration of each 285 scheme name. The registration process follows the guidelines 286 stipulated in [RFC4395], particularly where permanent URI scheme 287 registration is concerned. 289 2.2. Transport information as part of the URI authority 291 A single URI scheme, "coap-at" can be introduced, as part of an 292 absolute URI which expresses the transport information within the 293 authority component. One approach is to structure the component with 294 a transport prefix to the endpoint identifier and a delimiter, such 295 as "-endpoint_identifier". 297 Examples of resulting URIs are: 299 o coap-at://tcp-server.example.com/sensors/temperature 301 o coap-at://sms-0015105550101/sensors/temperature 303 An implementation note here is that some generic URI parsers will 304 fail when encountering a URI such as "coap-at://tcp-[2001:db8::1]/ 305 sensors/temperature". Consequently, an equivalent, but parseable URI 306 from the ip6.arpa domain needs to be formulated instead. For 307 [2001:db8::1] using TCP, this would result in the following URL: 309 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 310 .1.0.0.2.ip6.arpa:5683/sensors/temperature 312 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 313 similarly be expressed with a URI from the ip6.arpa domain. 315 2.2.1. Usage of DNS records 317 DNS names can be used instead of IPv6 address literals to mitigate 318 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 319 possible. 321 DNS SRV records can also be employed to formulate a URL such as: 323 coap-at://srv-_coap._tcp.example.com/sensors/temperature 325 in which the "srv" prefix is used to indicate that a DNS SRV lookup 326 should be used for _coap._tcp.example.com, where usage of CoAP over 327 TCP is specified for example.com, and is eventually resolved to a 328 numerical IPv4 or IPv6 address. 330 2.3. Transport information in URI without authority component 332 The CoAP URI used thus far is as follows: 334 URI = scheme ":" hier-part [ "?" query ] 335 hier-part = "//" authority path-abempty 337 A new URI format could be introduced, that does not possess an 338 "authority" component, and instead defining "hier-part" to instead 339 use another component, "path-rootless", as specified by RFC3986 340 [RFC3986]. The partial ABNF format of this URI would then be: 342 URI = scheme ":" hier-part [ "?" query ] 343 hier-part = path-rootless 344 path-rootless = segment-nz *( "/" segment ) 346 The full syntax of "path-rootless" is described in [RFC3986]. A 347 generic URI defined this way would conform to the syntax of 348 [RFC3986], while the path component can be treated as an opaque 349 string to indicate transport types, endpoints as well as paths to 350 CoAP resources. A single scheme can similarly be used. 352 When used this way, the URIs described in Section 2.1 for the TCP and 353 WebSocket endpoints would appear as: 355 o coap-at:tcp://server.example.com/sensors/temperature where "coap- 356 at" is the scheme and "tcp://server.example.com/sensors/ 357 temperature" is the path component that contains transport 358 endpoint information as well as the path to the resource 360 o coap-at:ws://www.example.com/WebSocket?/sensors/temperature where 361 "coap-at" is the scheme, "ws://www.example.com/WebSocket" is the 362 path component that contains the transport endpoint information 363 and "/sensors/temperature" is a query component that contains the 364 path to the resource from the WebSocket endpoint. 366 Implementation note: While square brackets are disallowed within the 367 path component, the '[' and ']' characters needed to enclose a 368 literal IPv6 address can be percent-encoded into their respective 369 equivalents. The ':' character does not need to be percent-encoded. 370 This results in a significantly simpler URI string compared to 371 section 2.2, particularly for compressed IPv6 addresses. 372 Additionally, the URI format can be used to specify other similar 373 address families and formats, such as Bluetooth. 375 2.3.1. Making CoAP Resources Available over Multiple Transports 376 A constrained node that is capable of communicating over several 377 types of transports (such as UDP, TCP and SMS) would be able to 378 convey a single CoAP resources over multiple transports. A key 379 challenge here is the avoidance of URI aliasing [WWWArchv1], namely, 380 a situation where several distinct URIs refer to the same resource. 382 Requesting and retrieving the same CoAP resource representation over 383 multiple transports could be rendered possible by prefixing the 384 transport type and endpoint identifier information to the CoAP URI. 385 This would result in the following example representation: 387 coap-at:tcp://example.com?coap://example.com/sensors/temperature 388 \_______ ______/ \________________ __________________/ 389 \/ \/ 390 Transport-specific CoAP Resource 391 Prefix 393 Figure 2: Prefixing a CoAP URI with TCP transport 395 Such a representation would result in the URI being decomposed into 396 its constituent components, with the CoAP resource residing within 397 the query component as follows: 399 Scheme: coap-at 401 Path: tcp://example.com 403 Query: coap://example.com/sensors/temperature 405 The same CoAP resource, if requested over a WebSocket transport, 406 would result the following URI: 408 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 409 \___________ __________/ \_______________ ___________________/ 410 \/ \/ 411 Transport-specific CoAP Resource 412 Prefix 414 Figure 3: Prefixing a CoAP URI with WebSocket transport 416 While the transport prefix changes, the CoAP resource representation 417 remains the same in the query component: 419 Scheme: coap-at 421 Path: ws://example.com/endpoint 423 Query: coap://example.com/sensors/temperature 425 3. Alternative Transport Analysis and Properties 427 In this section we consider the various characteristics of 428 alternative transports for successfully supporting various kinds of 429 functionality for CoAP. CoAP factors lossiness, unreliability, small 430 packet sizes and connection statelessness into its protocol logic. 431 We discuss general transport differences and their impact on carrying 432 CoAP packets here. Note that Properties 1, 2, and 3 are related. 434 Property 1: Uniqueness of an end-point identifier. 436 Transport protocols providing non-unique end-point IDs for nodes may 437 only convey a subset of the CoAP functionality. Such nodes may only 438 serve as CoAP servers that announce data at specific intervals to a 439 pre-specified end point, or to a shared medium. 441 Property 2: Unidirectional or bidirectional CoAP communication 442 support. 444 This refers to the ability of the CoAP end-point to use a single 445 transport channel for both request and response messages. Depending 446 on the scenario, having a unidirectional transport layer would mean 447 the CoAP end-point might utilise it only for outgoing data or 448 incoming data. Should both functionalities be needed, 2 449 unidirectional transport channels would be necessary. 451 Property 3: 1:N communication support. 453 This refers to the ability of the transport protocol to support 454 broadcast and multicast communication. CoAP's request/response 455 behaviour depends on unicast messaging. Group communication in CoAP 456 is bound to using multicasting. Therefore a protocol such as TCP 457 would be ill-suited for group communications using multicast. 458 Anycast support, where a message is sent to a well defined 459 destination address to which several nodes belong, on the other hand, 460 is supported by TCP. 462 Property 4: Transport-level reliability. 464 This refers to the ability of the transport protocol to provide a 465 guarantee of reliability against packet loss, ensuring ordered packet 466 delivery and having error control. When CoAP Request and Response 467 messages are delivered over such transports, the CoAP implementations 468 elide certain fields in the packet header. As an example, if the 469 usage of a connection-oriented transport renders it unnecessary to 470 specify the various CoAP message types, the Type field can be elided. 471 For some connection-oriented transports, such as WebSockets, the 472 version of CoAP being used can be negotiated during the opening 473 transfer. Consequently, the Version field in CoAP packets can also 474 be elided. 476 Property 5: Message encoding. 478 While parts of the CoAP payload are human readable or are transmitted 479 in XML, JSON or SenML format, CoAP is essentially a low overhead 480 binary protocol. Efficient transmission of such packets would 481 therefore be met with a transport offering binary encoding support, 482 although techniques exist in allowing binary payloads to be 483 transferred over text-based transport protocols such as base-64 484 encoding. A fuller discussion about performing CoAP message encoding 485 for SMS can be found in Appendix A.5 of [I-D.bormann-coap-misc] 487 Property 6: Network byte order. 489 CoAP, as well as transports based on the IP stack use a Big Endian 490 byte order for transmitting packets over the air or wire, while 491 transports based on Bluetooth and Zigbee prefer Little Endian byte 492 ordering for packet fields and transmission. Any CoAP implementation 493 that potentially uses multiple transports has to ensure correct byte 494 ordering for the transport used. 496 Property 7: MTU correlation with CoAP PDU size. 498 Section 4.6 of [I-D.ietf-core-coap] discusses the avoidance of IP 499 fragmentation by ensuring CoAP message fit into a single UDP 500 datagram. End-points on constrained networks using 6LoWPAN may use 501 blockwise transfers to accommodate even smaller packet sizes to avoid 502 fragmentation. The MTU sizes for Bluetooth Low Energy as well as 503 Classic Bluetooth are provided in Section 2.4 of 504 [I-D.ietf-6lowpan-btle]. Transport MTU correlation with CoAP 505 messages helps ensure minimal to no fragmentation at the transport 506 layer. On the other hand, allowing a CoAP message to be delivered 507 using a delay-tolerant transport service such as the Bundle Protocol 508 [RFC5050] would imply that the CoAP message may be fragmented (or 509 reconstituted) along various nodes in the DTN as various sized 510 bundles and bundle fragments. 512 Property 8: Framing 514 When using CoAP over a streaming transport protocol such as TCP, as 515 opposed to datagram based protocols, care must be observed in 516 preserving message boundaries. Commonly applied techniques at the 517 transport level include the use of delimiting characters for this 518 purpose as well as message framing and length prefixing. 520 Property 9: Transport latency. 522 A confirmable CoAP request would be retransmitted by a CoAP end-point 523 if a response is not obtained within a certain time. A CoAP end- 524 point registering to a Resource Directory uses a POST message that 525 could include a lifetime value. A sleepy end-point similarly uses a 526 lifetime value to indicate the freshness of the data to a CoAP Mirror 527 Server. Care needs to be exercised to ensure the latency of the 528 transport being used to carry CoAP packets is small enough not to 529 interfere with these values for the proper operation of these 530 functionalities. 532 Property 10: Connection Management. 534 A CoAP endpoint using a connection-oriented transport should be 535 responsible for proper connection establishment prior to sending a 536 CoAP Request message. Both communicating endpoints may monitor the 537 connection health during the Data Transfer phase. Finally, once data 538 transfer is complete, at least one end point should perform 539 connection teardown gracefully. 541 4. IANA Considerations 543 This memo includes no request to IANA. 545 5. Security Considerations 547 While we envisage no new security risks simply from the introduction 548 of support for alternative transports, end-applications and CoAP 549 implementations should take note if certain transports require 550 privacy trade-offs that may arise if identifiers such as MAC 551 addresses or phone numbers are made public in addition to FQDNs. 553 6. Acknowledgements 555 Feedback, ideas and ongoing discussions with Klaus Hartke, Martin 556 Thomson, Mark Nottingham, Graham Klyne, Carsten Bormann, Markus 557 Becker and Golnaz Karbaschi provided useful insights and ideas for 558 this work. 560 7. Informative References 562 [BTCorev4.0] 563 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 564 Version 4.0 ", June 2010. 566 [I-D.becker-core-coap-sms-gprs] 567 Becker, M., Li, K., Poetsch, T., and K. Kuladinithi, 568 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 569 gprs-04 (work in progress), August 2013. 571 [I-D.bormann-coap-misc] 572 Bormann, C. and K. Hartke, "Miscellaneous additions to 573 CoAP", draft-bormann-coap-misc-25 (work in progress), May 574 2013. 576 [I-D.bormann-core-coap-tcp] 577 Bormann, C., "A TCP transport for CoAP", draft-bormann- 578 core-coap-tcp-00 (work in progress), July 2013. 580 [I-D.ietf-6lowpan-btle] 581 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 582 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 583 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 584 (work in progress), February 2013. 586 [I-D.ietf-core-coap] 587 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 588 Application Protocol (CoAP)", draft-ietf-core-coap-18 589 (work in progress), June 2013. 591 [I-D.ietf-core-groupcomm] 592 Rahman, A. and E. Dijk, "Group Communication for CoAP", 593 draft-ietf-core-groupcomm-16 (work in progress), October 594 2013. 596 [I-D.ietf-core-observe] 597 Hartke, K., "Observing Resources in CoAP", draft-ietf- 598 core-observe-11 (work in progress), October 2013. 600 [I-D.jimenez-p2psip-coap-reload] 601 Jimenez, J., Lopez-Vega, J., Maenpaa, J., and G. 602 Camarillo, "A Constrained Application Protocol (CoAP) 603 Usage for REsource LOcation And Discovery (RELOAD)", 604 draft-jimenez-p2psip-coap-reload-03 (work in progress), 605 February 2013. 607 [I-D.savolainen-core-coap-websockets] 608 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 609 WebSockets", draft-savolainen-core-coap-websockets-01 610 (work in progress), October 2013. 612 [IANA-paparazzi-uri] 613 https://www.iana.org/assignments/uri-schemes/prov/ 614 paparazzi, "Resource Identifier (RI) Scheme name: 615 paparazzi ", September 2012. 617 [OMALWM2M] 618 Open Mobile Alliance (OMA), "Lightweight Machine to 619 Machine Technical Specification ", 2013. 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 625 and Service: Schemes", RFC 2609, June 1999. 627 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 629 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 630 Resource Identifier (URI): Generic Syntax", STD 66, RFC 631 3986, January 2005. 633 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 634 Registration Procedures for New URI Schemes", BCP 35, RFC 635 4395, February 2006. 637 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 638 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 639 Networking Architecture", RFC 4838, April 2007. 641 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 642 Specification", RFC 5050, November 2007. 644 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 645 November 2007. 647 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 648 6455, December 2011. 650 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 651 Application Spaces for IPv6 over Low-Power Wireless 652 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 654 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 655 "Diameter Base Protocol", RFC 6733, October 2012. 657 [WWWArchv1] 658 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 659 of the World Wide Web, Volume One ", December 2004. 661 Authors' Addresses 663 Bilhanan Silverajan 664 Tampere University of Technology 665 Korkeakoulunkatu 10 666 FI-33720 Tampere 667 Finland 669 Email: bilhanan.silverajan@tut.fi 671 Teemu Savolainen 672 Nokia 673 Hermiankatu 12 D 674 FI-33720 Tampere 675 Finland 677 Email: teemu.savolainen@nokia.com