idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 225 has weird spacing: '...ntifier ide...' -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC6568' is defined on line 510, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-becker-core-coap-sms-gprs-03 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-25 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-10 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 == 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-00 -- 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: 0 errors (**), 0 flaws (~~), 11 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: January 16, 2014 Nokia 6 July 15, 2013 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-02 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 January 16, 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 3. Alternative Transport Analysis and Properties . . . . . . . . 6 64 3.1. Other Considerations . . . . . . . . . . . . . . . . . . 9 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Informative References . . . . . . . . . . . . . . . . . . . 10 69 Appendix A. Expressing transport in the URI in other ways . . . 12 70 A.1. Transport in URI path or query component . . . . . . . . 12 71 A.2. Transport in the URI authority component . . . . . . . . 13 72 A.3. Transport as part of a 'service:' URL scheme . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is 78 being standardised by the CoRE WG as a lightweight, HTTP-like 79 protocol providing a request/response model that constrained nodes 80 can use to communicate with other nodes, be those servers, proxies, 81 gateways, less constrained nodes, or other constrained nodes. 83 As the Internet continues taking shape by integrating new kinds of 84 networks, services and devices, the need for a consistent, 85 lightweight method for resource representation, retrieval and 86 manipulation becomes evident. Owing to its simplicity and low 87 overhead, CoAP is a highly suitable protocol for this purpose. 88 However, the CoAP endpoint can reside in a non-IP network, be 89 separated from its peer by NATs and firewalls or simply has no 90 possibility to communicate over UDP. Consequently in addition to 91 UDP, alternative transport channels for conveying CoAP packets could 92 be considered. 94 This document looks at how CoAP can be used by nodes for resource 95 retrieval, in an end-to-end manner regardless of the transport 96 channel available. It looks at current usage of CoAP in this regard 97 today and provides other possible scenarios. Then the document looks 98 at how resources using CoAP can contain resource information that 99 provide endpoint as well as transport identifiers, without imposing 100 incompatibilities with [I-D.ietf-core-coap] and maintaining 101 conformance to [RFC3986]. 103 This draft does not discuss on application QoS requirements, user 104 policies or network adaptation, nor does it advocate replacing the 105 current practice of UDP-based CoAP communication. The scope of this 106 draft is limited towards a description and a requirements capture of 107 how CoAP packets can be transmitted over alternative transports, 108 especially how such protocols can be expressed at the CoAP layer, as 109 well as how CoAP packets can be mapped at transport level payloads. 111 1.1. Using Alternative Transports 113 Extending CoAP's REST-based usage over alternative transports allows 114 CoAP implementations to have a significantly larger relevance in 115 constrained as well as non-constrained networked environments. It 116 leads to better code optimisation in constrained nodes and 117 implementation reuse across new transport channels. As opposed to 118 implementing new resource retrieval schemes, an application in an 119 end-node can continue relying on using CoAP for this purpose, but 120 lets CoAP take into account the change in end point identification 121 and transport protocol. This simplifies development and memory 122 requirements. Resource representations are also visible in an end- 123 to-end manner for any CoAP client. 125 Inevitably, if two CoAP endpoints reside in distinctly separate 126 networks with orthogonal transports, a CoAP proxy node is needed 127 between the 2 networks so that CoAP Requests and Responses can be 128 fulfilled properly. The processing and computational overhead for 129 conveying CoAP packets from one underlying transport to another, 130 would be less than that of an application-level gateway performing 131 individual packet-based, protocol translation between CoAP to another 132 resource retrieval scheme. 134 1.2. Use Cases 136 CoAP has been designed to work on top of UDP, that is, on top of a 137 transport that can lose, reorder, and duplicate packets. UDP has 138 been chosen as the transport protocol over IP due its lightweight 139 nature and connectionless characteristics. In addition to point-to- 140 point communication, this allows multicast and group communications 141 [I-D.ietf-core-groupcomm]. Moreover, DTLS can be employed to secure 142 CoAP communication. 144 At this time of writing, the use of CoAP is also being specified for 145 other environments as follows: 147 1. CoAP Request and Response messages can be sent via SMS or USSD 148 between CoAP end-points in a cellular network 149 [I-D.becker-core-coap-sms-gprs]. A CoAP Request message can also 150 be sent via SMS from a CoAP client to a sleeping CoAP Server as a 151 wake-up mechanism for subsequent communication via GPRS. The 152 Open Mobile Alliance (OMA) specifies both UDP and SMS as 153 transports for M2M communication in cellular networks. The OMA 154 Lightweight M2M protocol being drafted uses CoAP, and as 155 transports, specifies both UDP binding as well as Short Message 156 Service (SMS) bindings [OMALWM2M] for the same reason. 158 2. The WebSocket protocol is being used as a transport channel 159 between WebSocket enabled CoAP end-points on the Internet 160 [I-D.savolainen-core-coap-websockets]. This is particularly 161 useful as a means for web browsers, particularly in smart 162 devices, to allow embedded client side scripts to upgrade an 163 existing HTTP connection to a WebSocket connection through which 164 CoAP Request and Response messages can be exchanged with a 165 WebSocket-enabled server. This also allows a browser containing 166 an embedded CoAP server to behave as a WebSocket client by 167 opening a connection to a WebSocket enabled CoAP Mirror Server to 168 register and update its resources. 170 3. [I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can 171 use a peer-to-peer overlay network called RELOAD, as a resource 172 caching facility for storing wireless sensor data. When a CoAP 173 node registers its resources with a RELOAD Proxy Node (PN), the 174 node computes a hash value from the CoAP URI and stores it as a 175 structure together with the PN's Node ID as well as the 176 resources. Resource retrieval by CoAP nodes is accomplished by 177 computing the hash key over the Request URI,opening a connection 178 to the overlay and using its message routing system to contact 179 the CoAP server via its PN. 181 We also envisage CoAP being extended atop other transport channels, 182 such as: 184 1. Using TCP to facilitate the traversal of CoAP Request and 185 Response messages. This allows easier communication between CoAP 186 clients and servers separated by firewalls and NATS. This also 187 allows CoAP messages to be transported over push notification 188 services from a notification server to a client app on a 189 smartphone, that may previously have subscribed to receive change 190 notifications of CoAP resource representations, possibly by using 191 CoAP Observe-functionality [I-D.ietf-core-observe]. 193 2. The transportation of CoAP messages in Delay-Tolerant Networks 194 [RFC4838], using the Bundle Protocol [RFC5050] for reaching 195 sensors in extremely challenging environments such as acoustic, 196 underwater and deep space networks. 198 3. Any type of non-IP networks supporting constrained nodes and low- 199 energy sensors, such as Bluetooth and Bluetooth Low Energy 200 (either through L2CAP or with GATT), ZigBee, Z-Wave, 1-Wire, 201 DASH7 and so on. 203 4. Instant Messaging and Social Networking channels, such as Jabber 204 and Twitter. 206 2. CoAP Transport URI 208 CoAP is logically divided into 2 sublayers, whereby a request/ 209 response layer is responsible for the protocol functionality of 210 exchanging request and response messages, while the messaging layer 211 is bound to UDP. These 2 sublayers are tightly coupled, both being 212 responsible for properly encoding the header and body of the CoAP 213 message. The COAP URI is used by both logical sublayers. For a URI 214 that is expressed generically as 216 URI = scheme ":" "//" authority path-abempty ["?"query ] 218 A simple example COAP URI, "coap://server.example.com/sensors/ 219 temperature" can be interpreted as follows: 221 coap :// server.example.com /sensors/temperature 222 \___/ \______ ________/ \______ _________/ 223 | \/ \/ 224 protocol endpoint parameterised 225 identifier identifier resource 226 identifier 228 Figure 1: The CoAP URI format 230 The resource path is explicitly expressed, and the endpoint 231 identifier, which contains the host address at the network-level is 232 also directly bound to the scheme name containing the application- 233 level protocol identifier. The choice of a specific transport for a 234 scheme, however, cannot be embedded with a URI, but is defined by 235 convention or standardisation of the protocol using the scheme. As 236 examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol 237 over TCP, while [RFC2818] requires that the 'https' protocol 238 identifier be used to differentiate using HTTP over TLS instead of 239 TCP. 241 To express an alternative transport binding to CoAP, a scheme name 242 can follow a convention of the form "coap+", where 243 the name of the transport is clearly and unambiguously described. 244 Each scheme name formed in this manner can be used to differentiate 245 the use of CoAP over an alternative transport instead of the use of 246 CoAP over UDP or DTLS. The endpoint identifier, path and query 247 components together with each scheme name would be used to uniquely 248 identify each resource. 250 Examples of such URIs are: 252 o coap://server.example.com/sensors/temperature for using CoAP over 253 UDP 255 o coaps://server.example.com/sensors/temperature for using CoAP over 256 DTLS 258 o coap+tel://+15105550101/sensors/temperature for using CoAP over 259 SMS or USSD with the endpoint identifier being a telephone 260 subscriber number 262 o coap+ws://www.example.com/WebSocket?/.well-known/core?rt=core.ms 263 for using CoAP over WebSockets with the endpoint at ws:// 264 www.example.com/WebSocket 266 o coap+ble.l2cap://[12:34:56:78:90:AB]:4/pulse where the scheme name 267 can possibly be used to describe the future use of CoAP over L2CAP 268 using Bluetooth Low Energy, but not L2CAP using classic Bluetooth. 270 When such a URI is provided from an end-application to its CoAP 271 implementation, the scheme name can be checked to allow the CoAP to 272 use the appropriate transport for the specified endpoint identifier. 273 The CoAP Transport URI can also be supplied as a Proxy-Uri option by 274 a CoAP end-point to a CoAP forward proxy in order to communicate with 275 a CoAP end-point residing in a network using a different transport. 276 Section 6.4 of [I-D.ietf-core-coap] provides an algorithm for parsing 277 the received URI to obtain the request's options. 279 3. Alternative Transport Analysis and Properties 280 In this section we consider the various characteristics of 281 alternative transports for successfully supporting various kinds of 282 functionality for CoAP. CoAP factors lossiness, unreliability, small 283 packet sizes and connection statelessness into its protocol logic. 284 We discuss general transport differences and their impact on carrying 285 CoAP packets here. Note that Properties 1, 2, and 3 are related. 287 Property 1: Uniqueness of an end-point identifier. 289 Transport protocols providing non-unique end-point IDs for nodes may 290 only convey a subset of the CoAP functionality. Such nodes may only 291 serve as CoAP servers that announce data at specific intervals to a 292 pre-specified end point, or to a shared medium. 294 Property 2: Unidirectional or bidirectional CoAP communication 295 support. 297 This refers to the ability of the CoAP end-point to use a single 298 transport channel for both request and response messages. Depending 299 on the scenario, having a unidirectional transport layer would mean 300 the CoAP end-point might utilise it only for outgoing data or 301 incoming data. Should both functionalities be needed, 2 302 unidirectional transport channels would be necessary. 304 Property 3: 1:N communication support. 306 This refers to the ability of the transport protocol to support 307 broadcast and multicast communication. CoAP's request/response 308 behaviour depends on unicast messaging. Group communication in CoAP 309 is bound to using multicasting. Therefore a protocol such as TCP 310 would be ill-suited for group communications using multicast. 311 Anycast support, where a message is sent to a well defined 312 destination address to which several nodes belong, on the other hand, 313 is supported by TCP. 315 Property 4: Transport-level reliability. 317 This refers to the ability of the transport protocol to provide a 318 guarantee of reliability against packet loss, ensuring ordered packet 319 delivery and having error control. When CoAP Request and Response 320 messages are delivered over such transports, the CoAP implementations 321 elide certain fields in the packet header. As an example, if the 322 usage of a connection-oriented transport renders it unnecessary to 323 specify the various CoAP message types, the Type field can be elided. 324 For some connection-oriented transports, such as WebSockets, the 325 version of CoAP being used can be negotiated during the opening 326 transfer. Consequently, the Version field in CoAP packets can also 327 be elided. 329 Property 5: Message encoding. 331 While parts of the CoAP payload are human readable or are transmitted 332 in XML, JSON or SenML format, CoAP is essentially a low overhead 333 binary protocol. Efficient transmission of such packets would 334 therefore be met with a transport offering binary encoding support, 335 although techniques exist in allowing binary payloads to be 336 transferred over text-based transport protocols such as base-64 337 encoding. A fuller discussion about performing CoAP message encoding 338 for SMS can be found in Appendix A.5 of [I-D.bormann-coap-misc] 340 Property 6: Network byte order. 342 CoAP, as well as transports based on the IP stack use a Big Endian 343 byte order for transmitting packets over the air or wire, while 344 transports based on Bluetooth and Zigbee prefer Little Endian byte 345 ordering for packet fields and transmission. Any CoAP implementation 346 that potentially uses multiple transports has to ensure correct byte 347 ordering for the transport used. 349 Property 7: MTU correlation with CoAP PDU size. 351 Section 4.6 of [I-D.ietf-core-coap] discusses the avoidance of IP 352 fragmentation by ensuring CoAP message fit into a single UDP 353 datagram. End-points on constrained networks using 6LoWPAN may use 354 blockwise transfers to accommodate even smaller packet sizes to avoid 355 fragmentation. The MTU sizes for Bluetooth Low Energy as well as 356 Classic Bluetooth are provided in Section 2.4 of 357 [I-D.ietf-6lowpan-btle]. Transport MTU correlation with CoAP 358 messages helps ensure minimal to no fragmentation at the transport 359 layer. On the other hand, allowing a CoAP message to be delivered 360 using a delay-tolerant transport service such as the Bundle Protocol 361 [RFC5050] would imply that the CoAP message may be fragmented (or 362 reconstituted) along various nodes in the DTN as various sized 363 bundles and bundle fragments. 365 Property 8: Transport latency. 367 A confirmable CoAP request would be retransmitted by a CoAP end-point 368 if a response is not obtained within a certain time. A CoAP end- 369 point registering to a Resource Directory uses a POST message that 370 could include a lifetime value. A sleepy end-point similarly uses a 371 lifetime value to indicate the freshness of the data to a CoAP Mirror 372 Server. Care needs to be exercised to ensure the latency of the 373 transport being used to carry CoAP packets is small enough not to 374 interfere with these values for the proper operation of these 375 functionalities. 377 3.1. Other Considerations 379 This section outlines miscellaneous considerations concerning 380 transport bindings with the CoAP URI. 382 1. A CoAP endpoint using a connection-oriented transport should be 383 responsible for proper connection establishment prior to sending 384 a CoAP Request message. Both communicating endpoints may monitor 385 the connection health during the Data Transfer phase. Finally, 386 once data transfer is complete, at least one end point should 387 perform connection teardown gracefully. 389 2. A CoAP server, such as a sensor, may make its data available over 390 multiple types of transports concurrently. For example, this can 391 be done to allow the value to be retrieved via UDP as well as 392 TCP. However, this could be carried out only when neccesary to 393 avoid a resource being identified by more than one URI. On the 394 other hand, when using only a single underlying transport, URI 395 aliasing should not be practised [WWWArchv1]. For some scenarios 396 where there is an availability of DNS for lookups as well as 397 updates, SRV records can be used. In these cases, the "_service" 398 field can be "coap", and the "_proto" field carries the name of 399 the transport to be used. 401 3. As the usage of each alternative transport results in an entirely 402 new scheme, IANA intervention is required for the registration of 403 each scheme name. The registration process follows the 404 guidelines stipulated in [RFC4395], particularly where permanent 405 URI scheme registration is concerned. 407 4. IANA Considerations 409 This memo includes no request to IANA. 411 5. Security Considerations 413 While we envisage no new security risks simply from the introduction 414 of support for alternative transports, end-applications and CoAP 415 implementations should take note if certain transports require 416 privacy trade-offs that may arise if identifiers such as MAC 417 addresses or phone numbers are made public in addition to FQDNs. 419 6. Acknowledgements 421 Discussions with Klaus Hartke, Graham Klyne, Markus Becker and Golnaz 422 Karbaschi provided useful insights and ideas for this draft. 424 7. Informative References 426 [BTCorev4.0] 427 BLUETOOTH Special Interest Group, "BLUETOOTH Specification 428 Version 4.0 ", June 2010. 430 [I-D.becker-core-coap-sms-gprs] 431 Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, 432 "Transport of CoAP over SMS, USSD and GPRS", draft-becker- 433 core-coap-sms-gprs-03 (work in progress), February 2013. 435 [I-D.bormann-coap-misc] 436 Bormann, C. and K. Hartke, "Miscellaneous additions to 437 CoAP", draft-bormann-coap-misc-25 (work in progress), May 438 2013. 440 [I-D.ietf-6lowpan-btle] 441 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 442 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 443 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 444 (work in progress), February 2013. 446 [I-D.ietf-core-coap] 447 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 448 Application Protocol (CoAP)", draft-ietf-core-coap-18 449 (work in progress), June 2013. 451 [I-D.ietf-core-groupcomm] 452 Rahman, A. and E. Dijk, "Group Communication for CoAP", 453 draft-ietf-core-groupcomm-10 (work in progress), July 454 2013. 456 [I-D.ietf-core-observe] 457 Hartke, K., "Observing Resources in CoAP", draft-ietf- 458 core-observe-08 (work in progress), February 2013. 460 [I-D.jimenez-p2psip-coap-reload] 461 Jimenez, J., Lopez-Vega, J., Maenpaa, J., and G. 462 Camarillo, "A Constrained Application Protocol (CoAP) 463 Usage for REsource LOcation And Discovery (RELOAD)", 464 draft-jimenez-p2psip-coap-reload-03 (work in progress), 465 February 2013. 467 [I-D.savolainen-core-coap-websockets] 468 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 469 WebSockets", draft-savolainen-core-coap-websockets-00 470 (work in progress), July 2013. 472 [IANA-paparazzi-uri] 473 https://www.iana.org/assignments/uri-schemes/prov/ 474 paparazzi, "Resource Identifier (RI) Scheme name: 475 paparazzi ", September 2012. 477 [OMALWM2M] 478 Open Mobile Alliance (OMA), "Lightweight Machine to 479 Machine Technical Specification ", 2013. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 485 and Service: Schemes", RFC 2609, June 1999. 487 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 489 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 490 Resource Identifier (URI): Generic Syntax", STD 66, RFC 491 3986, January 2005. 493 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 494 Registration Procedures for New URI Schemes", BCP 35, RFC 495 4395, February 2006. 497 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 498 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 499 Networking Architecture", RFC 4838, April 2007. 501 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 502 Specification", RFC 5050, November 2007. 504 [RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 505 November 2007. 507 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 508 6455, December 2011. 510 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 511 Application Spaces for IPv6 over Low-Power Wireless 512 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. 514 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 515 "Diameter Base Protocol", RFC 6733, October 2012. 517 [WWWArchv1] 518 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 519 of the World Wide Web, Volume One ", December 2004. 521 Appendix A. Expressing transport in the URI in other ways 523 Other means of indicating the transport as a distinguishable 524 component within the CoAP URI are possible, but have been deemed 525 unsuitable by working group consensus or because they violate 526 [RFC3986], and are incompatible with existing practices outlined in 527 [I-D.ietf-core-coap]. They are however, retained in this section for 528 historical documentation and completeness. 530 A.1. Transport in URI path or query component 532 For a URI that is expressed generically as 534 URI = scheme ":" "//" authority path-abempty [ "?"query ] 536 The transport protocol can alternatively be provided as a path or 537 query component. The Diameter Base Protocol [RFC6733] is one example 538 of a protocol that uses the "aaa" and "aaas" URI scheme names to 539 reflect whether transport security is used, and at the same time 540 provides the actual transport protocol to be used as a ";transport=" 541 path component. Example valid Diameter URIs are aaa:// 542 host.example.com;transport=sctp and aaas:// 543 host.example.com:6666;transport=tcp 545 Adopting such a procedure for CoAP can be done in two ways. The 546 first is to provide the transport as a path component, similar to the 547 Diameter protocol. An example resulting URI could be coap:// 548 host.example.com;transport=tcp/.well-known/core?rt=core-rd specifying 549 a CoAP endpoint discovering a Resource Directory and its base RD 550 resource while using TCP as a transport instead of UDP. A URI-Path 551 option would then be used to encode the transport used. 553 An alternative means of expressing the transport protocol used is to 554 encode the transport as a query component instead. In this case, the 555 resulting URI would then be coap://host.example.com/.well-known/ 556 core?rt=core-rd?tt=tcp where "tt" refers to the transport type. Such 557 a scheme would mean that the CoAP implementation encodes two URI- 558 query components. 560 It is also conceivable that an end point may wish to register its 561 available transports and associated end point identifiers in a CoAP 562 resource directory, and periodically update them. A "core-transport" 563 resource type or a "tt" link target attribute may then need to be 564 registered. 566 Encoding the transport as part of the URI path or query provides an 567 advantage in that IANA registration is not required, as opposed to 568 introducing new URI scheme names. New transports can be easily 569 introduced into the CoAP URI. As both the URI-Path and the URI-Query 570 options fall into the "critical" class of options, caution must be 571 exercised if an endpoint does not recognise them. In such cases, 572 section 5.4.1 in [I-D.ietf-core-coap] provides handling guidelines. 574 A.2. Transport in the URI authority component 576 An application-specific, provisional resource identifier registered 577 with IANA, has been done so by specifying the transport to be used as 578 part of the authority [IANA-paparazzi-uri]: 580 paparazzi:[options] http:[//host>[:[port][transport]]/ 582 While the URI is used by the application to obtain a screenshot of a 583 non-secure webpage, usage of the transport parameter is unclear and 584 if it is at all used. 586 A.3. Transport as part of a 'service:' URL scheme 588 The "service:" URL scheme name was introduced in [RFC2609] and forms 589 the basis of service description used primarily by the Service 590 Location Protocol. An abstract service type URI would have the form 592 "service::" 594 where refers to a service type name that can be 595 associated with a variety of protocols, while the 596 then providing the specific details of the protocol used, authority 597 and other URI components. 599 Adopting the "service:" URL scheme to describe CoAP usage over 600 alternative transports would be rather trivial. To use a previous 601 example, a CoAP service to discover a Resource Directory and its base 602 RD resource using TCP would take the form 604 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 606 The syntax of the "service:" URL scheme differs from the generic URI 607 syntax and therefore such a representation should be treated as an 608 opaque URI as Section 2.1 of [RFC2609] recommends. 610 Authors' Addresses 611 Bilhanan Silverajan 612 Tampere University of Technology 613 Korkeakoulunkatu 10 614 FI-33720 Tampere 615 Finland 617 Email: bilhanan.silverajan@tut.fi 619 Teemu Savolainen 620 Nokia 621 Hermiankatu 12 D 622 FI-33720 Tampere 623 Finland 625 Email: teemu.savolainen@nokia.com