idnits 2.17.1 draft-silverajan-core-coap-alternative-transports-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2489 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 (-11) exists of draft-ietf-core-coap-tcp-tls-09 Summary: 2 errors (**), 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: January 4, 2018 Nokia Technologies 6 July 3, 2017 8 CoAP Communication with Alternative Transports 9 draft-silverajan-core-coap-alternative-transports-10 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 http://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 January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 11 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 such as TCP, TLS, 91 WebSockets and SMS. These allow CoAP to better address firewall and 92 NAT traversal issues, to operate in Web browser-based and HTML5 93 applications as well as for energy-constrained M2M communication in 94 cellular networks. 96 CoAP uses a REST-based model similar to HTTP, where URIs are used to 97 identify resources at servers. An important factor of allowing CoAP 98 communication over alternative transports, is to express not only the 99 resource identifier, but also the alternative transport information 100 in the URI. 102 CoAP URIs contain information, such as the endpoint address as well 103 as the location of the resource hosted at the endpoint. CoAP URIs 104 beginning with "coap://" are using UDP, while those beginning with 105 "coaps://" are using DTLS. 107 coap :// server.example.org /sensors/temperature 108 \___/ \______ ________/ \______ _________/ 109 | \/ \/ 110 URI scheme URI authority URI path 112 Figure 1: A CoAP URI 114 Figure 1 shows the structure of a simple example CoAP URI, in which 115 the various URI components can beinterpreted as follows: 117 o The URI scheme component (e.g. "coap") contains an application- 118 level identifier which typically identifies the protocol being 119 used as well as its transport and network level protocol 120 configurations. Such configurations are defined by convention or 121 standardisation of the protocol using the scheme. 123 o The URI authority component ("server.example.com") contains the 124 endpoint identification, which is typically a fully qualified 125 domain name or a network-level host address. 127 o The URI path component ("/sensors/temperature") contains a 128 parameterised resource identifier providing the location and 129 identity of the resource at the endpoint. 131 In addition to these URI components, Figure 2 shows how specific 132 queries on resource representations are provided by CoAP clients to 133 servers, by specifying one or more URI query components in the URI. 135 coap :// server.example.org /sensors/temperature ?u=cel 136 \___/ 137 | 138 URI query 140 Figure 2: A CoAP URI with query 142 This document focuses on how CoAP URIs can be extended to contain 143 information about alternative transports. For deriving the new URI 144 format, the main design considerations are presented in the next 145 section. Following that, various potential URIs are presented. 146 These URIs provide examples of how transport identifiers can be 147 situated in the URI scheme, authority, path or query components. The 148 proposed URIs are analysed to select feasible formats while 149 disqualifying those not meeting the design criteria. 151 2. Conformance and Design Considerations 153 In order to understand which URI formats are best suited for 154 expressing transport information, certain considerations firstly need 155 to be taken into account. Doing so eliminates URI formats that do 156 not meet or conform to the stated requirements. The main criteria 157 are: 159 1. Conformance to the generic syntax for a URI described in 160 [RFC3986]. A URI format needs to be described in which each URI 161 component clearly meets the syntax and percent-encoding rules 162 described. 164 2. Alignment with best practices for URI design, as described in 165 [RFC7320]. This is particularly important when it pertains to 166 establishing or standardising the structure and usage of URIs 167 with respect to the various URI components. 169 3. Request messages sent to a CoAP endpoint using a CoAP Transport 170 URI may be responded to with a relative URI reference. [RFC3986] 171 provides an algorithm to establish how relative references can be 172 resolved against a base URI to obtain a target URI. Given this 173 algorithm, a URI format needs to be described in which relative 174 reference resolution does not result in a target URI that loses 175 its transport-specific information 177 4. The URI can be supplied as a Proxy-Uri option by a CoAP end-point 178 to a CoAP forward proxy. This allows communication with a CoAP 179 end-point residing in a network using a different transport. 180 Section 6.4 of [RFC7252] provides an algorithm for parsing a 181 received URI to obtain the request's options. Conformance to 183 [RFC3986] is also necessary in order for the parsing algorithm to 184 be successful. 186 In addition to the above mentioned requirements, where possible, the 187 following considerations need to be borne in mind: 189 1. The URI format is able to represent a resource and the transport 190 information for use in constrained environments, without 191 requiring the presence of a naming infrastructure, such as DNS or 192 a directory/lookup service. 194 2. Alternative transport information can be easily retrieved by 195 computationally constrained nodes. In other words, the URI 196 format does not result in unneccessarily complex code or logic in 197 such nodes to parse and extract the transport to be used, nor the 198 endpoint address. 200 3. URIs are designed to uniquely identify resources. When a single 201 resource is represented with multiple URIs, URI aliasing 202 [WWWArchv1] occurs. Avoiding URI aliasing is considered good 203 practice. 205 4. CoAP URIs do not support fragment identifiers. 207 3. Situating Transport Information in CoAP URIs 209 The following subsections aim to describe potential URI formats in 210 which the alternative transport information is placed in various URI 211 components. 213 3.1. Using the URI scheme component 215 Expressing the transport information in the URI scheme component can 216 be achieved by using new schemes. These can conform to an agreed- 217 upon convention such as "coap+alternative_transport_name" for each 218 new alternative transport and/or "coaps+alternative_transport_name" 219 for its secure counterpart. 221 Examples of such URIs are: 223 o coap+tcp://server.example.org/sensors/temperature for using CoAP 224 over TCP 226 o coap+sms://0015105550101/sensors/temperature for using CoAP over 227 SMS with the endpoint identifier being a telephone subscriber 228 number 230 o coaps+tcp://server.example.org/sensors/temperature for using CoAP 231 over TLS 233 3.1.1. Analysis 235 Expressing transport information in the URI scheme delivers a URI 236 which is human-readable and computationally as easy to parse as 237 standard CoAP URIs, to extract transport identification information. 238 The URI syntax conforms to [RFC3986], and relative URI resolution 239 does not result in the loss of transport identification information. 240 However, each new alternative transport requires minting new schemes, 241 and IANA intervention is required for the registration of each scheme 242 name. The registration process follows the guidelines stipulated in 243 [RFC7595]. Additionally, should a CoAP server wish to expose its 244 resources over multiple transports (such as both UDP and TCP) , URI 245 aliasing can occur if the URI scheme components of these multiple 246 URIs differ in describing the same resource. 248 3.2. Using the URI authority component 250 Expressing the transport information within the authority component 251 can result in two possible URI formats. 253 The first approach is to structure the URI authority's host sub- 254 component with a transport prefix to the endpoint identifier and a 255 delimiter, such as "-endpoint_identifier". 257 Examples of resulting URIs are: 259 o coap://tcp-server.example.org/sensors/temperature for using CoAP 260 over TCP 262 o coap://sms-0015105550101/sensors/temperature for using CoAP over 263 SMS 265 The second approach is to hint at the alternative transport 266 information, by explicitly specifying using the URI authority's port 267 sub-component, thereby differentiating them from standard CoAP URIs. 269 Examples of resulting URIs are: 271 o coap://server.example.org:5684/sensors/temperature for using CoAP 272 over TLS 274 o coap://server.example.org:80/sensors/temperature for using CoAP 275 over WebSockets 277 3.2.1. Analysis 279 Embedding the transport information in the host would violate the 280 guidelines for the structure of URI authorities in section 2.2 of 281 [RFC7320]. Consequently, the host in a URI authority component 282 cannot be used as a basis for a new CoAP URI for alternative 283 transports. 285 Embedding the transport information in the port, on the other hand, 286 would not violate the guidelines for the structure of URI authorities 287 in section 2.2 of [RFC7320]. It would result in a CoAP URI that is 288 less human-readable, but URI aliasing is minimised. 290 On the other hand, if a CoAP request message using a CoAP Transport 291 URI of this form elicits a CoAP Response containing a relative URI, 292 for example, of the form "//server2.example.org/path/to/another/ 293 resource", relative URI resolution rules of [RFC3986] would result in 294 the loss of transport identification information. Consequently, 295 using the URI authority component cannot be used as a basis for a new 296 CoAP URI for alternative transports. 298 3.3. Using the URI path component 300 Should the URI path component be used, then special characters or 301 keywords need to be supplied in the path to make the transport 302 explicit. Here, many proposals can exist. In general however, this 303 will result in a URI format such as: 305 o coap://server.example.org/sensors/temperature;tcp for using CoAP 306 over TCP, by appending the transport information at the end of the 307 URI. 309 3.3.1. Analysis 311 Embedding the transport information in the URI path directly results 312 in a URI that is human-readable. However, if a CoAP request message 313 using a CoAP Transport URI of this form elicits a CoAP Response 314 containing a relative URI, for example, of the form 315 "../../path/to/another/resource", relative URI resolution rules of 316 [RFC3986] would result in the loss of transport identification 317 information. Consequently, using the URI path component cannot be 318 used as a basis for a new CoAP URI for alternative transports. 320 3.4. Using the URI query component 322 The alternative transport information, should URI query components be 323 used, would result in a URI format such as: 325 o coap://server.example.org/sensors/temperature?alternative- 326 transport=wss for using CoAP over secure WebSockets. 328 3.4.1. Analysis 330 Embedding the transport information in a URI query also results in a 331 URI that is human-readable. However, if a CoAP request message using 332 a CoAP Transport URI of this form elicits a CoAP Response containing 333 a relative URI, for example, of the form "../../path/to/another/ 334 resource", relative URI resolution rules of [RFC3986] would result in 335 the loss of transport identification information. Consequently, 336 using the URI query component cannot be used as a basis for a new 337 CoAP URI for alternative transports. 339 4. Discussion 341 Based on the analysis of the various options for embedding 342 alternative transport information in a CoAP URI, the most technically 343 feasible option is to use the URI scheme component, as described in 344 Section 3.1. To date, this has also been the WG consensus. 346 A discussion with IESG members during review of 347 [I-D.ietf-core-coap-tcp-tls] revealed however, that using the URI 348 scheme to express transport information is not desirable, to avoid 349 the proliferation of new URI schemes for the same application-layer 350 protocol. A strategy was instead proposed to preserve the existing 351 CoAP URI and reuse it for alternative transports, by employing a 352 combination of UDP Confirmable messages and timeouts to determine the 353 eventual correct transport to use between a client and server 354 [IESG-feedback]. The undertaken strategy would have obvious 355 implications regarding interoperability, application and protocol 356 logic, resource usage, for both new CoAP and existing CoAP 357 implementations and deployments. Although URI aliasing can 358 theoretically be avoided with this approach, at the time of writing, 359 its technical feasibility over using the simpler strategy of using 360 URI schemes, has yet to be validated. An obvious drawback is 361 therefore that implementers and other SDOs may choose to 362 provisionally or permanently register new URI schemes with IANA, for 363 CoAP over alternative transports anyway, as was done by the Open 364 Connectivity Foundation (OCF) [CoAP-TCP-TLS-registration]. 366 5. IANA Considerations 368 This memo includes no request to IANA. 370 6. Security Considerations 372 New security risks are not envisaged to arise from the guidelines 373 given in this document, for describing a new URI format containing 374 transport identification within the URI scheme component. However, 375 when specific alternative transports are selected for implementing 376 support for carrying CoAP messages, risk factors or vulnerabilities 377 can be present. Examples include privacy trade-offs when MAC 378 addresses or phone numbers are supplied as URI authority components, 379 or if specific URI path components employed for security-specific 380 interpretations are accidentally encountered as false positives. 381 While this document does not make it mandatory to introduce a 382 security mode with each transport, it recommends ascribing meaning to 383 the use of "coap+" and "coaps+" prefixes in the scheme component, 384 with the "coaps+" prefix used for secure transports for CoAP 385 messages. 387 7. Acknowledgements 389 Email discussions, comments and ideas from Thomas Fossati, Akbar 390 Rahman, Klaus Hartke, Martin Thomson, Mark Nottingham, Dave Thaler, 391 Graham Klyne, Carsten Bormann and Markus Becker greatly helped 392 previous versions of this draft. 394 8. References 396 8.1. Normative References 398 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 399 Resource Identifier (URI): Generic Syntax", STD 66, 400 RFC 3986, DOI 10.17487/RFC3986, January 2005, 401 . 403 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 404 Application Protocol (CoAP)", RFC 7252, 405 DOI 10.17487/RFC7252, June 2014, 406 . 408 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 409 RFC 7320, DOI 10.17487/RFC7320, July 2014, 410 . 412 8.2. Informative References 414 [CoAP-TCP-TLS-registration] 415 https://www.iana.org/assignments/uri-schemes/prov/coap+tcp 416 , https://www.iana.org/assignments/uri-schemes/prov/ 417 coaps+tcp, , June 2017. 419 [I-D.ietf-core-coap-tcp-tls] 420 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 421 Silverajan, B., and B. Raymor, "CoAP (Constrained 422 Application Protocol) over TCP, TLS, and WebSockets", 423 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 424 2017. 426 [IESG-feedback] 427 https://www.ietf.org/mail-archive/web/core/current/ 428 msg08768.html, , May 2017. 430 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 431 and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609, 432 June 1999, . 434 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 435 and Registration Procedures for URI Schemes", BCP 35, 436 RFC 7595, DOI 10.17487/RFC7595, June 2015, 437 . 439 [WWWArchv1] 440 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 441 of the World Wide Web, Volume One", December 2004. 443 Appendix A. Expressing transport in the URI in other ways 445 Other means of indicating the transport as a distinguishable 446 component within the CoAP URI are possible, but have been deemed 447 unsuitable by not meeting the design considerations listed, or are 448 incompatible with existing practices outlined in [RFC7252]. They are 449 however, retained in this section for historical documentation and 450 completeness. 452 A.1. Transport information as part of the URI authority 454 A single URI scheme, "coap-at" can be introduced, as part of an 455 absolute URI which expresses the transport information within the 456 authority component. One approach is to structure the component with 457 a transport prefix to the endpoint identifier and a delimiter, such 458 as "-endpoint_identifier". 460 Examples of resulting URIs are: 462 o coap-at://tcp-server.example.com/sensors/temperature 464 o coap-at://sms-0015105550101/sensors/temperature 465 An implementation note here is that some generic URI parsers will 466 fail when encountering a URI such as "coap-at://tcp- 467 [2001:db8::1]/sensors/temperature". Consequently, an equivalent, but 468 parseable URI from the ip6.arpa domain needs to be formulated 469 instead. For [2001:db8::1] using TCP, this would result in the 470 following URL: 472 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 473 .1.0.0.2.ip6.arpa:5683/sensors/temperature 475 Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can 476 similarly be expressed with a URI from the ip6.arpa domain. 478 This URI format allows the usage of a single scheme to represent 479 multiple types of transport end-points. Consequently, it requires 480 consistency in ensuring how various transport-specific endpoints are 481 identified, as a single URI format is used. Attention must be paid 482 towards the syntax rules and encoding for the URI host component. 483 Additionally, against a base URI of the form "coap-at://tcp- 484 server.example.com/sensors/temperature", resolving a relative 485 reference, such as "//example.net/sensors/temperature" would result 486 in the target URI "coap-at://example.net/sensors/temperature", in 487 which transport information is lost. 489 A.1.1. Usage of DNS records 491 DNS names can be used instead of IPv6 address literals to mitigate 492 lengthy URLs referring to the ip6.arpa domain, if usage of DNS is 493 possible. 495 DNS SRV records can also be employed to formulate a URL such as: 497 coap-at://srv-_coap._tcp.example.com/sensors/temperature 499 in which the "srv" prefix is used to indicate that a DNS SRV lookup 500 should be used for _coap._tcp.example.com, where usage of CoAP over 501 TCP is specified for example.com, and is eventually resolved to a 502 numerical IPv4 or IPv6 address. 504 A.2. Making CoAP Resources Available over Multiple Transports 506 The CoAP URI used thus far is as follows: 508 URI = scheme ":" hier-part [ "?" query ] 509 hier-part = "//" authority path-abempty 511 A new URI format could be introduced, that does not possess an 512 "authority" component, and instead defining "hier-part" to instead 513 use another component, "path-rootless", as specified by RFC3986 514 [RFC3986]. The partial ABNF format of this URI would then be: 516 URI = scheme ":" hier-part [ "?" query ] 517 hier-part = path-rootless 518 path-rootless = segment-nz *( "/" segment ) 520 The full syntax of "path-rootless" is described in [RFC3986]. A 521 generic URI defined this way would conform to the syntax of 522 [RFC3986], while the path component can be treated as an opaque 523 string to indicate transport types, endpoints as well as paths to 524 CoAP resources. A single scheme can similarly be used. 526 A constrained node that is capable of communicating over several 527 types of transports (such as UDP, TCP and SMS) would be able to 528 convey a single CoAP resource over multiple transports. This is also 529 beneficial for nodes performing caching and proxying from one type of 530 transport to another. 532 Requesting and retrieving the same CoAP resource representation over 533 multiple transports could be rendered possible by prefixing the 534 transport type and endpoint identifier information to the CoAP URI. 535 This would result in the following example representation: 537 coap-at:tcp://example.com?coap://example.com/sensors/temperature 538 \_______ ______/ \________________ __________________/ 539 \/ \/ 540 Transport-specific CoAP Resource 541 Prefix 543 Figure 3: Prefixing a CoAP URI with TCP transport 545 Such a representation would result in the URI being decomposed into 546 its constituent components, with the CoAP resource residing within 547 the query component as follows: 549 Scheme: coap-at 551 Path: tcp://example.com 552 Query: coap://example.com/sensors/temperature 554 The same CoAP resource, if requested over a WebSocket transport, 555 would result the following URI: 557 coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature 558 \___________ __________/ \_______________ ___________________/ 559 \/ \/ 560 Transport-specific CoAP Resource 561 Prefix 563 Figure 4: Prefixing a CoAP URI with WebSocket transport 565 While the transport prefix changes, the CoAP resource representation 566 remains the same in the query component: 568 Scheme: coap-at 570 Path: ws://example.com/endpoint 572 Query: coap://example.com/sensors/temperature 574 The URI format described here overcomes URI aliasing [WWWArchv1] when 575 multiple transports are used, by ensuring each CoAP resource 576 representation remains the same, but is prefixed with different 577 transports. However, against a base URI of this format, resolving 578 relative references of the form "//example.net/sensors/temperature" 579 and "/sensor2/temperature" would again result in target URIs which 580 lose transport-specific information. 582 Implementation note: While square brackets are disallowed within the 583 path component, the '[' and ']' characters needed to enclose a 584 literal IPv6 address can be percent-encoded into their respective 585 equivalents. The ':' character does not need to be percent-encoded. 586 This results in a significantly simpler URI string compared to 587 section 2.2, particularly for compressed IPv6 addresses. 588 Additionally, the URI format can be used to specify other similar 589 address families and formats, such as Bluetooth addresses. 591 A.3. Transport as part of a 'service:' URL scheme 593 The "service:" URL scheme name was introduced in [RFC2609] and forms 594 the basis of service description used primarily by the Service 595 Location Protocol. An abstract service type URI would have the form 596 "service::" 598 where refers to a service type name that can be 599 associated with a variety of protocols, while the 600 then providing the specific details of the protocol used, authority 601 and other URI components. 603 Adopting the "service:" URL scheme to describe CoAP usage over 604 alternative transports would be rather trivial. To use a previous 605 example, a CoAP service to discover a Resource Directory and its base 606 RD resource using TCP would take the form 608 service:coap:tcp://host.example.com/.well-known/core?rt=core-rd 610 The syntax of the "service:" URL scheme differs from the generic URI 611 syntax and therefore such a representation should be treated as an 612 opaque URI as Section 2.1 of [RFC2609] recommends. 614 Authors' Addresses 616 Bilhanan Silverajan 617 Tampere University of Technology 618 Korkeakoulunkatu 10 619 FI-33720 Tampere 620 Finland 622 Email: bilhanan.silverajan@tut.fi 624 Teemu Savolainen 625 Nokia Technologies 626 Hatanpaeaen valtatie 30 627 FI-33100 Tampere 628 Finland 630 Email: teemu.savolainen@nokia.com