idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-11.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 -- The document date (March 5, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: A later version (-03) exists of draft-bormann-t2trg-slipmux-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: September 6, 2018 Nokia Technologies 6 March 5, 2018 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-11 11 Abstract 13 The aim of this document is to provide a way forward to best decide 14 upon how alternative transport information can be expressed in a CoAP 15 URI. This draft examines the requirements for a new URI format for 16 representing CoAP resources over alternative transports. Various 17 potential URI formats are presented. Benefits and drawbacks of 18 embedding alternative transport information in various ways within 19 the URI components are also discussed. From all listed formats, the 20 document finds scheme-based model to be the most technically 21 feasible. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conformance and Design Considerations . . . . . . . . . . . . 4 59 3. Situating Transport Information in CoAP URIs . . . . . . . . 5 60 3.1. Using the URI scheme component . . . . . . . . . . . . . 5 61 3.1.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Using the URI authority component . . . . . . . . . . . . 6 63 3.2.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 7 64 3.3. Using the URI path component . . . . . . . . . . . . . . 7 65 3.3.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 7 66 3.4. Using the URI query component . . . . . . . . . . . . . . 7 67 3.4.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Expressing transport in the URI in other ways . . . 10 76 A.1. Transport information as part of the URI authority . . . 10 77 A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 11 78 A.2. Making CoAP Resources Available over Multiple Transports 12 79 A.3. Transport as part of a 'service:' URL scheme . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 The Constrained Application Protocol (CoAP) [RFC7252] is a 85 lightweight, binary application layer protocol designed for 86 constrained environments. Owing to its operating environment, CoAP 87 uses UDP and DTLS as its underlying transports between communicating 88 endpoints. However, with an increase in deployment experiences as 89 well as its popularity, compelling reasons exist for extending CoAP 90 messaging to work over alternative transports. These allow CoAP to 91 better address firewall and NAT traversal issues, to operate in Web 92 browser-based and HTML5 applications as well as for energy- 93 constrained M2M communication in cellular networks. At the time of 94 writing, these transports are: 96 o TCP, TLS and Websockets [RFC8323] 97 o SMS for cellular networks[I-D.becker-core-coap-sms-gprs] 99 o SLIP for serial interfaces[I-D.bormann-t2trg-slipmux] 101 CoAP uses a REST-based model similar to HTTP, where URIs are used to 102 identify resources at servers. An important factor of allowing CoAP 103 communication over alternative transports, is to express not only the 104 resource identifier, but also the alternative transport information 105 in the URI. 107 CoAP URIs contain information, such as the endpoint address as well 108 as the location of the resource hosted at the endpoint. CoAP URIs 109 beginning with "coap://" are using UDP, while those beginning with 110 "coaps://" are using DTLS. 112 coap :// server.example.org /sensors/temperature 113 \___/ \______ ________/ \______ _________/ 114 | \/ \/ 115 URI scheme URI authority URI path 117 Figure 1: A CoAP URI 119 Figure 1 shows the structure of a simple example CoAP URI, in which 120 the various URI components can beinterpreted as follows: 122 o The URI scheme component (e.g. "coap") contains an application- 123 level identifier which typically identifies the protocol being 124 used as well as its transport and network level protocol 125 configurations. Such configurations are defined by convention or 126 standardisation of the protocol using the scheme. 128 o The URI authority component ("server.example.com") contains the 129 endpoint identification, which is typically a fully qualified 130 domain name or a network-level host address. 132 o The URI path component ("/sensors/temperature") contains a 133 parameterised resource identifier providing the location and 134 identity of the resource at the endpoint. 136 In addition to these URI components, Figure 2 shows how specific 137 queries on resource representations are provided by CoAP clients to 138 servers, by specifying one or more URI query components in the URI. 140 coap :// server.example.org /sensors/temperature ?u=cel 141 \___/ 142 | 143 URI query 145 Figure 2: A CoAP URI with query 147 This document focuses on how CoAP URIs can be extended to contain 148 information about alternative transports. For deriving the new URI 149 format, the main design considerations are presented in the next 150 section. Following that, various potential URIs are presented. 151 These URIs provide examples of how transport identifiers can be 152 situated in the URI scheme, authority, path or query components. The 153 proposed URIs are analysed to select feasible formats while 154 disqualifying those not meeting the design criteria. 156 2. Conformance and Design Considerations 158 In order to understand which URI formats are best suited for 159 expressing transport information, certain considerations firstly need 160 to be taken into account. Doing so eliminates URI formats that do 161 not meet or conform to the stated requirements. The main criteria 162 are: 164 1. Conformance to the generic syntax for a URI described in 165 [RFC3986]. A URI format needs to be described in which each URI 166 component clearly meets the syntax and percent-encoding rules 167 described. 169 2. Alignment with best practices for URI design, as described in 170 [RFC7320]. This is particularly important when it pertains to 171 establishing or standardising the structure and usage of URIs 172 with respect to the various URI components. 174 3. Request messages sent to a CoAP endpoint using a CoAP Transport 175 URI may be responded to with a relative URI reference. [RFC3986] 176 provides an algorithm to establish how relative references can be 177 resolved against a base URI to obtain a target URI. Given this 178 algorithm, a URI format needs to be described in which relative 179 reference resolution does not result in a target URI that loses 180 its transport-specific information 182 4. The URI can be supplied as a Proxy-Uri option by a CoAP end-point 183 to a CoAP forward proxy. This allows communication with a CoAP 184 end-point residing in a network using a different transport. 185 Section 6.4 of [RFC7252] provides an algorithm for parsing a 186 received URI to obtain the request's options. Conformance to 188 [RFC3986] is also necessary in order for the parsing algorithm to 189 be successful. 191 In addition to the above mentioned requirements, where possible, the 192 following considerations need to be borne in mind: 194 1. The URI format is able to represent a resource and the transport 195 information for use in constrained environments, without 196 requiring the presence of a naming infrastructure, such as DNS or 197 a directory/lookup service. 199 2. Alternative transport information can be easily retrieved by 200 computationally constrained nodes. In other words, the URI 201 format does not result in unneccessarily complex code or logic in 202 such nodes to parse and extract the transport to be used, nor the 203 endpoint address. 205 3. URIs are designed to uniquely identify resources. When a single 206 resource is represented with multiple URIs, URI aliasing 207 [WWWArchv1] occurs. Avoiding URI aliasing is considered good 208 practice. 210 4. CoAP URIs do not support fragment identifiers. 212 3. Situating Transport Information in CoAP URIs 214 The following subsections aim to describe potential URI formats in 215 which the alternative transport information is placed in various URI 216 components. 218 3.1. Using the URI scheme component 220 Expressing the transport information in the URI scheme component can 221 be achieved by using new schemes. These can conform to an agreed- 222 upon convention such as "coap+alternative_transport_name" for each 223 new alternative transport and/or "coaps+alternative_transport_name" 224 for its secure counterpart. 226 Examples of such URIs are: 228 o coap+tcp://server.example.org/sensors/temperature for using CoAP 229 over TCP 231 o coap+sms://0015105550101/sensors/temperature for using CoAP over 232 SMS with the endpoint identifier being a telephone subscriber 233 number 235 o coaps+tcp://server.example.org/sensors/temperature for using CoAP 236 over TLS 238 3.1.1. Analysis 240 Expressing transport information in the URI scheme delivers a URI 241 which is human-readable and computationally as easy to parse as 242 standard CoAP URIs, to extract transport identification information. 243 The URI syntax conforms to [RFC3986], and relative URI resolution 244 does not result in the loss of transport identification information. 245 However, each new alternative transport requires minting new schemes, 246 and IANA intervention is required for the registration of each scheme 247 name. The registration process follows the guidelines stipulated in 248 [RFC7595]. Additionally, should a CoAP server wish to expose its 249 resources over multiple transports (such as both UDP and TCP) , URI 250 aliasing can occur if the URI scheme components of these multiple 251 URIs differ in describing the same resource. 253 3.2. Using the URI authority component 255 Expressing the transport information within the authority component 256 can result in two possible URI formats. 258 The first approach is to structure the URI authority's host sub- 259 component with a transport prefix to the endpoint identifier and a 260 delimiter, such as "-endpoint_identifier". 262 Examples of resulting URIs are: 264 o coap://tcp-server.example.org/sensors/temperature for using CoAP 265 over TCP 267 o coap://sms-0015105550101/sensors/temperature for using CoAP over 268 SMS 270 The second approach is to hint at the alternative transport 271 information, by explicitly specifying using the URI authority's port 272 sub-component, thereby differentiating them from standard CoAP URIs. 274 Examples of resulting URIs are: 276 o coap://server.example.org:5684/sensors/temperature for using CoAP 277 over TLS 279 o coap://server.example.org:80/sensors/temperature for using CoAP 280 over WebSockets 282 3.2.1. Analysis 284 Embedding the transport information in the host would violate the 285 guidelines for the structure of URI authorities in section 2.2 of 286 [RFC7320]. Consequently, the host in a URI authority component 287 cannot be used as a basis for a new CoAP URI for alternative 288 transports. 290 Embedding the transport information in the port, on the other hand, 291 would not violate the guidelines for the structure of URI authorities 292 in section 2.2 of [RFC7320]. It would result in a CoAP URI that is 293 less human-readable, but URI aliasing is minimised. 295 On the other hand, if a CoAP request message using a CoAP Transport 296 URI of this form elicits a CoAP Response containing a relative URI, 297 for example, of the form "//server2.example.org/path/to/another/ 298 resource", relative URI resolution rules of [RFC3986] would result in 299 the loss of transport identification information. Consequently, 300 using the URI authority component cannot be used as a basis for a new 301 CoAP URI for alternative transports. 303 3.3. Using the URI path component 305 Should the URI path component be used, then special characters or 306 keywords need to be supplied in the path to make the transport 307 explicit. Here, many proposals can exist. In general however, this 308 will result in a URI format such as: 310 o coap://server.example.org/sensors/temperature;tcp for using CoAP 311 over TCP, by appending the transport information at the end of the 312 URI. 314 3.3.1. Analysis 316 Embedding the transport information in the URI path directly results 317 in a URI that is human-readable. However, if a CoAP request message 318 using a CoAP Transport URI of this form elicits a CoAP Response 319 containing a relative URI, for example, of the form 320 "../../path/to/another/resource", relative URI resolution rules of 321 [RFC3986] would result in the loss of transport identification 322 information. Consequently, using the URI path component cannot be 323 used as a basis for a new CoAP URI for alternative transports. 325 3.4. Using the URI query component 327 The alternative transport information, should URI query components be 328 used, would result in a URI format such as: 330 o coap://server.example.org/sensors/temperature?alternative- 331 transport=wss for using CoAP over secure WebSockets. 333 3.4.1. Analysis 335 Embedding the transport information in a URI query also results in a 336 URI that is human-readable. However, if a CoAP request message using 337 a CoAP Transport URI of this form elicits a CoAP Response containing 338 a relative URI, for example, of the form "../../path/to/another/ 339 resource", relative URI resolution rules of [RFC3986] would result in 340 the loss of transport identification information. Consequently, 341 using the URI query component cannot be used as a basis for a new 342 CoAP URI for alternative transports. 344 4. Discussion 346 Based on the analysis of the various options for embedding 347 alternative transport information in a CoAP URI, the most technically 348 feasible option is to use the URI scheme component, as described in 349 Section 3.1. To date, this has also been the WG consensus. 351 A discussion with IESG members during review of [RFC8323] revealed 352 however, that using the URI scheme to express transport information 353 is not desirable, to avoid the proliferation of new URI schemes for 354 the same application-layer protocol. A strategy was instead proposed 355 to preserve the existing CoAP URI and reuse it for alternative 356 transports, by employing a combination of UDP Confirmable messages 357 and timeouts to determine the eventual correct transport to use 358 between a client and server [IESG-feedback]. The undertaken strategy 359 would have obvious implications regarding interoperability, 360 application and protocol logic, resource usage, for both new CoAP and 361 existing CoAP implementations and deployments. Although URI aliasing 362 can theoretically be avoided with this approach, at the time of 363 writing, its technical feasibility over using the simpler strategy of 364 using URI schemes, has yet to be validated. An obvious drawback is 365 therefore that implementers and other SDOs may choose to 366 provisionally or permanently register new URI schemes with IANA, for 367 CoAP over alternative transports anyway, as was done by the Open 368 Connectivity Foundation (OCF) [CoAP-TCP-TLS-registration]. 370 5. IANA Considerations 372 This memo includes no request to IANA. 374 6. Security Considerations 376 New security risks are not envisaged to arise from the guidelines 377 given in this document, for describing a new URI format containing 378 transport identification within the URI scheme component. However, 379 when specific alternative transports are selected for implementing 380 support for carrying CoAP messages, risk factors or vulnerabilities 381 can be present. Examples include privacy trade-offs when MAC 382 addresses or phone numbers are supplied as URI authority components, 383 or if specific URI path components employed for security-specific 384 interpretations are accidentally encountered as false positives. 385 While this document does not make it mandatory to introduce a 386 security mode with each transport, it recommends ascribing meaning to 387 the use of "coap+" and "coaps+" prefixes in the scheme component, 388 with the "coaps+" prefix used for secure transports for CoAP 389 messages. 391 7. Acknowledgements 393 Email discussions, comments and ideas from Thomas Fossati, Akbar 394 Rahman, Klaus Hartke, Martin Thomson, Mark Nottingham, Dave Thaler, 395 Graham Klyne, Carsten Bormann and Markus Becker greatly helped 396 previous versions of this draft. 398 8. References 400 8.1. Normative References 402 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 403 Resource Identifier (URI): Generic Syntax", STD 66, 404 RFC 3986, DOI 10.17487/RFC3986, January 2005, 405 . 407 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 408 Application Protocol (CoAP)", RFC 7252, 409 DOI 10.17487/RFC7252, June 2014, 410 . 412 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 413 RFC 7320, DOI 10.17487/RFC7320, July 2014, 414 . 416 8.2. Informative References 418 [CoAP-TCP-TLS-registration] 419 , . 421 [I-D.becker-core-coap-sms-gprs] 422 Kuladinithi, K., Becker, M., Li, K., and T. Poetsch, 423 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 424 gprs-06 (work in progress), February 2017. 426 [I-D.bormann-t2trg-slipmux] 427 Bormann, C. and T. Kaupat, "Slipmux: Using an UART 428 interface for diagnostics, configuration, and packet 429 transfer", draft-bormann-t2trg-slipmux-02 (work in 430 progress), January 2018. 432 [IESG-feedback] 433 , . 436 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 437 and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609, 438 June 1999, . 440 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 441 and Registration Procedures for URI Schemes", BCP 35, 442 RFC 7595, DOI 10.17487/RFC7595, June 2015, 443 . 445 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 446 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 447 Application Protocol) over TCP, TLS, and WebSockets", 448 RFC 8323, DOI 10.17487/RFC8323, February 2018, 449 . 451 [WWWArchv1] 452 , . 454 Appendix A. Expressing transport in the URI in other ways 456 Other means of indicating the transport as a distinguishable 457 component within the CoAP URI are possible, but have been deemed 458 unsuitable by not meeting the design considerations listed, or are 459 incompatible with existing practices outlined in [RFC7252]. They are 460 however, retained in this section for historical documentation and 461 completeness. 463 A.1. Transport information as part of the URI authority 465 A single URI scheme, "coap-at" can be introduced, as part of an 466 absolute URI which expresses the transport information within the 467 authority component. One approach is to structure the component with 468 a transport prefix to the endpoint identifier and a delimiter, such 469 as "-endpoint_identifier". 471 Examples of resulting URIs are: 473 o coap-at://tcp-server.example.com/sensors/temperature 475 o coap-at://sms-0015105550101/sensors/temperature 477 An implementation note here is that some generic URI parsers will 478 fail when encountering a URI such as "coap-at://tcp- 479 [2001:db8::1]/sensors/temperature". Consequently, an equivalent, but 480 parseable URI from the ip6.arpa domain needs to be formulated 481 instead. For [2001:db8::1] using TCP, this would result in the 482 following URL: 484 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 485 .1.0.0.2.ip6.arpa:5683/sensors/temperature 487 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 488 similarly be expressed with a URI from the ip6.arpa domain. 490 This URI format allows the usage of a single scheme to represent 491 multiple types of transport end-points. Consequently, it requires 492 consistency in ensuring how various transport-specific endpoints are 493 identified, as a single URI format is used. Attention must be paid 494 towards the syntax rules and encoding for the URI host component. 495 Additionally, against a base URI of the form "coap-at://tcp- 496 server.example.com/sensors/temperature", resolving a relative 497 reference, such as "//example.net/sensors/temperature" would result 498 in the target URI "coap-at://example.net/sensors/temperature", in 499 which transport information is lost. 501 A.1.1. Usage of DNS records 503 DNS names can be used instead of IPv6 address literals to mitigate 504 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 505 possible. 507 DNS SRV records can also be employed to formulate a URL such as: 509 coap-at://srv-_coap._tcp.example.com/sensors/temperature 511 in which the "srv" prefix is used to indicate that a DNS SRV lookup 512 should be used for _coap._tcp.example.com, where usage of CoAP over 513 TCP is specified for example.com, and is eventually resolved to a 514 numerical IPv4 or IPv6 address. 516 A.2. Making CoAP Resources Available over Multiple Transports 518 The CoAP URI used thus far is as follows: 520 URI = scheme ":" hier-part [ "?" query ] 521 hier-part = "//" authority path-abempty 523 A new URI format could be introduced, that does not possess an 524 "authority" component, and instead defining "hier-part" to instead 525 use another component, "path-rootless", as specified by RFC3986 526 [RFC3986]. The partial ABNF format of this URI would then be: 528 URI = scheme ":" hier-part [ "?" query ] 529 hier-part = path-rootless 530 path-rootless = segment-nz *( "/" segment ) 532 The full syntax of "path-rootless" is described in [RFC3986]. A 533 generic URI defined this way would conform to the syntax of 534 [RFC3986], while the path component can be treated as an opaque 535 string to indicate transport types, endpoints as well as paths to 536 CoAP resources. A single scheme can similarly be used. 538 A constrained node that is capable of communicating over several 539 types of transports (such as UDP, TCP and SMS) would be able to 540 convey a single CoAP resource over multiple transports. This is also 541 beneficial for nodes performing caching and proxying from one type of 542 transport to another. 544 Requesting and retrieving the same CoAP resource representation over 545 multiple transports could be rendered possible by prefixing the 546 transport type and endpoint identifier information to the CoAP URI. 547 This would result in the following example representation: 549 coap-at:tcp://example.com?coap://example.com/sensors/temperature 550 \_______ ______/ \________________ __________________/ 551 \/ \/ 552 Transport-specific CoAP Resource 553 Prefix 555 Figure 3: Prefixing a CoAP URI with TCP transport 557 Such a representation would result in the URI being decomposed into 558 its constituent components, with the CoAP resource residing within 559 the query component as follows: 561 Scheme: coap-at 563 Path: tcp://example.com 564 Query: coap://example.com/sensors/temperature 566 The same CoAP resource, if requested over a WebSocket transport, 567 would result the following URI: 569 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 570 \___________ __________/ \_______________ ___________________/ 571 \/ \/ 572 Transport-specific CoAP Resource 573 Prefix 575 Figure 4: Prefixing a CoAP URI with WebSocket transport 577 While the transport prefix changes, the CoAP resource representation 578 remains the same in the query component: 580 Scheme: coap-at 582 Path: ws://example.com/endpoint 584 Query: coap://example.com/sensors/temperature 586 The URI format described here overcomes URI aliasing [WWWArchv1] when 587 multiple transports are used, by ensuring each CoAP resource 588 representation remains the same, but is prefixed with different 589 transports. However, against a base URI of this format, resolving 590 relative references of the form "//example.net/sensors/temperature" 591 and "/sensor2/temperature" would again result in target URIs which 592 lose transport-specific information. 594 Implementation note: While square brackets are disallowed within the 595 path component, the '[' and ']' characters needed to enclose a 596 literal IPv6 address can be percent-encoded into their respective 597 equivalents. The ':' character does not need to be percent-encoded. 598 This results in a significantly simpler URI string compared to 599 section 2.2, particularly for compressed IPv6 addresses. 600 Additionally, the URI format can be used to specify other similar 601 address families and formats, such as Bluetooth addresses. 603 A.3. Transport as part of a 'service:' URL scheme 605 The "service:" URL scheme name was introduced in [RFC2609] and forms 606 the basis of service description used primarily by the Service 607 Location Protocol. An abstract service type URI would have the form 608 "service::" 610 where refers to a service type name that can be 611 associated with a variety of protocols, while the 612 then providing the specific details of the protocol used, authority 613 and other URI components. 615 Adopting the "service:" URL scheme to describe CoAP usage over 616 alternative transports would be rather trivial. To use a previous 617 example, a CoAP service to discover a Resource Directory and its base 618 RD resource using TCP would take the form 620 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 622 The syntax of the "service:" URL scheme differs from the generic URI 623 syntax and therefore such a representation should be treated as an 624 opaque URI as Section 2.1 of [RFC2609] recommends. 626 Authors' Addresses 628 Bilhanan Silverajan 629 Tampere University of Technology 630 Korkeakoulunkatu 10 631 FI-33720 Tampere 632 Finland 634 Email: bilhanan.silverajan@tut.fi 636 Teemu Savolainen 637 Nokia Technologies 638 Hatanpaeaen valtatie 30 639 FI-33100 Tampere 640 Finland 642 Email: teemu.savolainen@nokia.com