[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

CoRE Working Group                                         B. Silverajan
Internet-Draft                          Tampere University of Technology
Intended status: Informational                             T. Savolainen
Expires: January 4, 2018                              Nokia Technologies
                                                            July 3, 2017


             CoAP Communication with Alternative Transports
          draft-silverajan-core-coap-alternative-transports-10

Abstract

   The aim of this document is to provide a way forward to best decide
   upon how alternative transport information can be expressed in a CoAP
   URI.  This draft examines the requirements for a new URI format for
   representing CoAP resources over alternative transports.  Various
   potential URI formats are presented.  Benefits and drawbacks of
   embedding alternative transport information in various ways within
   the URI components are also discussed.  From all listed formats, the
   document finds scheme-based model to be the most technically
   feasible.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Silverajan & Savolainen  Expires January 4, 2018                [Page 1]


Internet-Draft         CoAP Alternative Transports             July 2017


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conformance and Design Considerations . . . . . . . . . . . .   4
   3.  Situating Transport Information in CoAP URIs  . . . . . . . .   5
     3.1.  Using the URI scheme component  . . . . . . . . . . . . .   5
       3.1.1.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Using the URI authority component . . . . . . . . . . . .   6
       3.2.1.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Using the URI path component  . . . . . . . . . . . . . .   7
       3.3.1.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Using the URI query component . . . . . . . . . . . . . .   7
       3.4.1.  Analysis  . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Expressing transport in the URI in other ways  . . .  10
     A.1.  Transport information as part of the URI authority  . . .  10
       A.1.1.  Usage of DNS records  . . . . . . . . . . . . . . . .  11
     A.2.  Making CoAP Resources Available over Multiple Transports   11
     A.3.  Transport as part of a 'service:' URL scheme  . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a
   lightweight, binary application layer protocol designed for
   constrained environments.  Owing to its operating environment, CoAP
   uses UDP and DTLS as its underlying transports between communicating
   endpoints.  However, with an increase in deployment experiences as
   well as its popularity, compelling reasons exist for extending CoAP
   messaging to work over alternative transports such as TCP, TLS,
   WebSockets and SMS.  These allow CoAP to better address firewall and
   NAT traversal issues, to operate in Web browser-based and HTML5
   applications as well as for energy-constrained M2M communication in
   cellular networks.





Silverajan & Savolainen  Expires January 4, 2018                [Page 2]


Internet-Draft         CoAP Alternative Transports             July 2017


   CoAP uses a REST-based model similar to HTTP, where URIs are used to
   identify resources at servers.  An important factor of allowing CoAP
   communication over alternative transports, is to express not only the
   resource identifier, but also the alternative transport information
   in the URI.

   CoAP URIs contain information, such as the endpoint address as well
   as the location of the resource hosted at the endpoint.  CoAP URIs
   beginning with "coap://" are using UDP, while those beginning with
   "coaps://" are using DTLS.



      coap :// server.example.org /sensors/temperature
      \___/    \______  ________/  \______  _________/
        |             \/                  \/
    URI scheme   URI authority         URI path


                           Figure 1: A CoAP URI

   Figure 1 shows the structure of a simple example CoAP URI, in which
   the various URI components can beinterpreted as follows:

   o  The URI scheme component (e.g. "coap") contains an application-
      level identifier which typically identifies the protocol being
      used as well as its transport and network level protocol
      configurations.  Such configurations are defined by convention or
      standardisation of the protocol using the scheme.

   o  The URI authority component ("server.example.com") contains the
      endpoint identification, which is typically a fully qualified
      domain name or a network-level host address.

   o  The URI path component ("/sensors/temperature") contains a
      parameterised resource identifier providing the location and
      identity of the resource at the endpoint.

   In addition to these URI components, Figure 2 shows how specific
   queries on resource representations are provided by CoAP clients to
   servers, by specifying one or more URI query components in the URI.










Silverajan & Savolainen  Expires January 4, 2018                [Page 3]


Internet-Draft         CoAP Alternative Transports             July 2017


      coap :// server.example.org /sensors/temperature ?u=cel
                                                        \___/
                                                          |
                                                      URI query


                      Figure 2: A CoAP URI with query

   This document focuses on how CoAP URIs can be extended to contain
   information about alternative transports.  For deriving the new URI
   format, the main design considerations are presented in the next
   section.  Following that, various potential URIs are presented.
   These URIs provide examples of how transport identifiers can be
   situated in the URI scheme, authority, path or query components.  The
   proposed URIs are analysed to select feasible formats while
   disqualifying those not meeting the design criteria.

2.  Conformance and Design Considerations

   In order to understand which URI formats are best suited for
   expressing transport information, certain considerations firstly need
   to be taken into account.  Doing so eliminates URI formats that do
   not meet or conform to the stated requirements.  The main criteria
   are:

   1.  Conformance to the generic syntax for a URI described in
       [RFC3986].  A URI format needs to be described in which each URI
       component clearly meets the syntax and percent-encoding rules
       described.

   2.  Alignment with best practices for URI design, as described in
       [RFC7320].  This is particularly important when it pertains to
       establishing or standardising the structure and usage of URIs
       with respect to the various URI components.

   3.  Request messages sent to a CoAP endpoint using a CoAP Transport
       URI may be responded to with a relative URI reference.  [RFC3986]
       provides an algorithm to establish how relative references can be
       resolved against a base URI to obtain a target URI.  Given this
       algorithm, a URI format needs to be described in which relative
       reference resolution does not result in a target URI that loses
       its transport-specific information

   4.  The URI can be supplied as a Proxy-Uri option by a CoAP end-point
       to a CoAP forward proxy.  This allows communication with a CoAP
       end-point residing in a network using a different transport.
       Section 6.4 of [RFC7252] provides an algorithm for parsing a
       received URI to obtain the request's options.  Conformance to



Silverajan & Savolainen  Expires January 4, 2018                [Page 4]


Internet-Draft         CoAP Alternative Transports             July 2017


       [RFC3986] is also necessary in order for the parsing algorithm to
       be successful.

   In addition to the above mentioned requirements, where possible, the
   following considerations need to be borne in mind:

   1.  The URI format is able to represent a resource and the transport
       information for use in constrained environments, without
       requiring the presence of a naming infrastructure, such as DNS or
       a directory/lookup service.

   2.  Alternative transport information can be easily retrieved by
       computationally constrained nodes.  In other words, the URI
       format does not result in unneccessarily complex code or logic in
       such nodes to parse and extract the transport to be used, nor the
       endpoint address.

   3.  URIs are designed to uniquely identify resources.  When a single
       resource is represented with multiple URIs, URI aliasing
       [WWWArchv1] occurs.  Avoiding URI aliasing is considered good
       practice.

   4.  CoAP URIs do not support fragment identifiers.

3.  Situating Transport Information in CoAP URIs

   The following subsections aim to describe potential URI formats in
   which the alternative transport information is placed in various URI
   components.

3.1.  Using the URI scheme component

   Expressing the transport information in the URI scheme component can
   be achieved by using new schemes.  These can conform to an agreed-
   upon convention such as "coap+alternative_transport_name" for each
   new alternative transport and/or "coaps+alternative_transport_name"
   for its secure counterpart.

   Examples of such URIs are:

   o  coap+tcp://server.example.org/sensors/temperature for using CoAP
      over TCP

   o  coap+sms://0015105550101/sensors/temperature for using CoAP over
      SMS with the endpoint identifier being a telephone subscriber
      number





Silverajan & Savolainen  Expires January 4, 2018                [Page 5]


Internet-Draft         CoAP Alternative Transports             July 2017


   o  coaps+tcp://server.example.org/sensors/temperature for using CoAP
      over TLS

3.1.1.  Analysis

   Expressing transport information in the URI scheme delivers a URI
   which is human-readable and computationally as easy to parse as
   standard CoAP URIs, to extract transport identification information.
   The URI syntax conforms to [RFC3986], and relative URI resolution
   does not result in the loss of transport identification information.
   However, each new alternative transport requires minting new schemes,
   and IANA intervention is required for the registration of each scheme
   name.  The registration process follows the guidelines stipulated in
   [RFC7595].  Additionally, should a CoAP server wish to expose its
   resources over multiple transports (such as both UDP and TCP) , URI
   aliasing can occur if the URI scheme components of these multiple
   URIs differ in describing the same resource.

3.2.  Using the URI authority component

   Expressing the transport information within the authority component
   can result in two possible URI formats.

   The first approach is to structure the URI authority's host sub-
   component with a transport prefix to the endpoint identifier and a
   delimiter, such as "<transport-name>-endpoint_identifier".

   Examples of resulting URIs are:

   o  coap://tcp-server.example.org/sensors/temperature for using CoAP
      over TCP

   o  coap://sms-0015105550101/sensors/temperature for using CoAP over
      SMS

   The second approach is to hint at the alternative transport
   information, by explicitly specifying using the URI authority's port
   sub-component, thereby differentiating them from standard CoAP URIs.

   Examples of resulting URIs are:

   o  coap://server.example.org:5684/sensors/temperature for using CoAP
      over TLS

   o  coap://server.example.org:80/sensors/temperature for using CoAP
      over WebSockets





Silverajan & Savolainen  Expires January 4, 2018                [Page 6]


Internet-Draft         CoAP Alternative Transports             July 2017


3.2.1.  Analysis

   Embedding the transport information in the host would violate the
   guidelines for the structure of URI authorities in section 2.2 of
   [RFC7320].  Consequently, the host in a URI authority component
   cannot be used as a basis for a new CoAP URI for alternative
   transports.

   Embedding the transport information in the port, on the other hand,
   would not violate the guidelines for the structure of URI authorities
   in section 2.2 of [RFC7320].  It would result in a CoAP URI that is
   less human-readable, but URI aliasing is minimised.

   On the other hand, if a CoAP request message using a CoAP Transport
   URI of this form elicits a CoAP Response containing a relative URI,
   for example, of the form "//server2.example.org/path/to/another/
   resource", relative URI resolution rules of [RFC3986] would result in
   the loss of transport identification information.  Consequently,
   using the URI authority component cannot be used as a basis for a new
   CoAP URI for alternative transports.

3.3.  Using the URI path component

   Should the URI path component be used, then special characters or
   keywords need to be supplied in the path to make the transport
   explicit.  Here, many proposals can exist.  In general however, this
   will result in a URI format such as:

   o  coap://server.example.org/sensors/temperature;tcp for using CoAP
      over TCP, by appending the transport information at the end of the
      URI.

3.3.1.  Analysis

   Embedding the transport information in the URI path directly results
   in a URI that is human-readable.  However, if a CoAP request message
   using a CoAP Transport URI of this form elicits a CoAP Response
   containing a relative URI, for example, of the form
   "../../path/to/another/resource", relative URI resolution rules of
   [RFC3986] would result in the loss of transport identification
   information.  Consequently, using the URI path component cannot be
   used as a basis for a new CoAP URI for alternative transports.

3.4.  Using the URI query component

   The alternative transport information, should URI query components be
   used, would result in a URI format such as:




Silverajan & Savolainen  Expires January 4, 2018                [Page 7]


Internet-Draft         CoAP Alternative Transports             July 2017


   o  coap://server.example.org/sensors/temperature?alternative-
      transport=wss for using CoAP over secure WebSockets.

3.4.1.  Analysis

   Embedding the transport information in a URI query also results in a
   URI that is human-readable.  However, if a CoAP request message using
   a CoAP Transport URI of this form elicits a CoAP Response containing
   a relative URI, for example, of the form "../../path/to/another/
   resource", relative URI resolution rules of [RFC3986] would result in
   the loss of transport identification information.  Consequently,
   using the URI query component cannot be used as a basis for a new
   CoAP URI for alternative transports.

4.  Discussion

   Based on the analysis of the various options for embedding
   alternative transport information in a CoAP URI, the most technically
   feasible option is to use the URI scheme component, as described in
   Section 3.1.  To date, this has also been the WG consensus.

   A discussion with IESG members during review of
   [I-D.ietf-core-coap-tcp-tls] revealed however, that using the URI
   scheme to express transport information is not desirable, to avoid
   the proliferation of new URI schemes for the same application-layer
   protocol.  A strategy was instead proposed to preserve the existing
   CoAP URI and reuse it for alternative transports, by employing a
   combination of UDP Confirmable messages and timeouts to determine the
   eventual correct transport to use between a client and server
   [IESG-feedback].  The undertaken strategy would have obvious
   implications regarding interoperability, application and protocol
   logic, resource usage, for both new CoAP and existing CoAP
   implementations and deployments.  Although URI aliasing can
   theoretically be avoided with this approach, at the time of writing,
   its technical feasibility over using the simpler strategy of using
   URI schemes, has yet to be validated.  An obvious drawback is
   therefore that implementers and other SDOs may choose to
   provisionally or permanently register new URI schemes with IANA, for
   CoAP over alternative transports anyway, as was done by the Open
   Connectivity Foundation (OCF) [CoAP-TCP-TLS-registration].

5.  IANA Considerations

   This memo includes no request to IANA.







Silverajan & Savolainen  Expires January 4, 2018                [Page 8]


Internet-Draft         CoAP Alternative Transports             July 2017


6.  Security Considerations

   New security risks are not envisaged to arise from the guidelines
   given in this document, for describing a new URI format containing
   transport identification within the URI scheme component.  However,
   when specific alternative transports are selected for implementing
   support for carrying CoAP messages, risk factors or vulnerabilities
   can be present.  Examples include privacy trade-offs when MAC
   addresses or phone numbers are supplied as URI authority components,
   or if specific URI path components employed for security-specific
   interpretations are accidentally encountered as false positives.
   While this document does not make it mandatory to introduce a
   security mode with each transport, it recommends ascribing meaning to
   the use of "coap+" and "coaps+" prefixes in the scheme component,
   with the "coaps+" prefix used for secure transports for CoAP
   messages.

7.  Acknowledgements

   Email discussions, comments and ideas from Thomas Fossati, Akbar
   Rahman, Klaus Hartke, Martin Thomson, Mark Nottingham, Dave Thaler,
   Graham Klyne, Carsten Bormann and Markus Becker greatly helped
   previous versions of this draft.

8.  References

8.1.  Normative References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190,
              RFC 7320, DOI 10.17487/RFC7320, July 2014,
              <http://www.rfc-editor.org/info/rfc7320>.

8.2.  Informative References

   [CoAP-TCP-TLS-registration]
              https://www.iana.org/assignments/uri-schemes/prov/coap+tcp
              , https://www.iana.org/assignments/uri-schemes/prov/
              coaps+tcp, , June 2017.



Silverajan & Savolainen  Expires January 4, 2018                [Page 9]


Internet-Draft         CoAP Alternative Transports             July 2017


   [I-D.ietf-core-coap-tcp-tls]
              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              draft-ietf-core-coap-tcp-tls-09 (work in progress), May
              2017.

   [IESG-feedback]
              https://www.ietf.org/mail-archive/web/core/current/
              msg08768.html, , May 2017.

   [RFC2609]  Guttman, E., Perkins, C., and J. Kempf, "Service Templates
              and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609,
              June 1999, <http://www.rfc-editor.org/info/rfc2609>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <http://www.rfc-editor.org/info/rfc7595>.

   [WWWArchv1]
              http://www.w3.org/TR/webarch/#uri-aliases, "Architecture
              of the World Wide Web, Volume One", December 2004.

Appendix A.  Expressing transport in the URI in other ways

   Other means of indicating the transport as a distinguishable
   component within the CoAP URI are possible, but have been deemed
   unsuitable by not meeting the design considerations listed, or are
   incompatible with existing practices outlined in [RFC7252].  They are
   however, retained in this section for historical documentation and
   completeness.

A.1.  Transport information as part of the URI authority

   A single URI scheme, "coap-at" can be introduced, as part of an
   absolute URI which expresses the transport information within the
   authority component.  One approach is to structure the component with
   a transport prefix to the endpoint identifier and a delimiter, such
   as "<transport-name>-endpoint_identifier".

   Examples of resulting URIs are:

   o  coap-at://tcp-server.example.com/sensors/temperature

   o  coap-at://sms-0015105550101/sensors/temperature





Silverajan & Savolainen  Expires January 4, 2018               [Page 10]


Internet-Draft         CoAP Alternative Transports             July 2017


   An implementation note here is that some generic URI parsers will
   fail when encountering a URI such as "coap-at://tcp-
   [2001:db8::1]/sensors/temperature".  Consequently, an equivalent, but
   parseable URI from the ip6.arpa domain needs to be formulated
   instead.  For [2001:db8::1] using TCP, this would result in the
   following URL:

   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
   .1.0.0.2.ip6.arpa:5683/sensors/temperature

   Usage of an IPv4-mapped IPv6 address such as [::ffff.192.100.0.1] can
   similarly be expressed with a URI from the ip6.arpa domain.

   This URI format allows the usage of a single scheme to represent
   multiple types of transport end-points.  Consequently, it requires
   consistency in ensuring how various transport-specific endpoints are
   identified, as a single URI format is used.  Attention must be paid
   towards the syntax rules and encoding for the URI host component.
   Additionally, against a base URI of the form "coap-at://tcp-
   server.example.com/sensors/temperature", resolving a relative
   reference, such as "//example.net/sensors/temperature" would result
   in the target URI "coap-at://example.net/sensors/temperature", in
   which transport information is lost.

A.1.1.  Usage of DNS records

   DNS names can be used instead of IPv6 address literals to mitigate
   lengthy URLs referring to the ip6.arpa domain, if usage of DNS is
   possible.

   DNS SRV records can also be employed to formulate a URL such as:

   coap-at://srv-_coap._tcp.example.com/sensors/temperature

   in which the "srv" prefix is used to indicate that a DNS SRV lookup
   should be used for _coap._tcp.example.com, where usage of CoAP over
   TCP is specified for example.com, and is eventually resolved to a
   numerical IPv4 or IPv6 address.

A.2.  Making CoAP Resources Available over Multiple Transports

   The CoAP URI used thus far is as follows:


        URI         = scheme ":" hier-part [ "?" query ]
        hier-part   = "//" authority path-abempty





Silverajan & Savolainen  Expires January 4, 2018               [Page 11]


Internet-Draft         CoAP Alternative Transports             July 2017


   A new URI format could be introduced, that does not possess an
   "authority" component, and instead defining "hier-part" to instead
   use another component, "path-rootless", as specified by RFC3986
   [RFC3986].  The partial ABNF format of this URI would then be:


         URI         = scheme ":" hier-part [ "?" query ]
         hier-part   = path-rootless
         path-rootless = segment-nz *( "/" segment )


   The full syntax of "path-rootless" is described in [RFC3986].  A
   generic URI defined this way would conform to the syntax of
   [RFC3986], while the path component can be treated as an opaque
   string to indicate transport types, endpoints as well as paths to
   CoAP resources.  A single scheme can similarly be used.

   A constrained node that is capable of communicating over several
   types of transports (such as UDP, TCP and SMS) would be able to
   convey a single CoAP resource over multiple transports.  This is also
   beneficial for nodes performing caching and proxying from one type of
   transport to another.

   Requesting and retrieving the same CoAP resource representation over
   multiple transports could be rendered possible by prefixing the
   transport type and endpoint identifier information to the CoAP URI.
   This would result in the following example representation:



   coap-at:tcp://example.com?coap://example.com/sensors/temperature
           \_______  ______/ \________________  __________________/
                   \/                         \/
            Transport-specific            CoAP Resource
                Prefix



             Figure 3: Prefixing a CoAP URI with TCP transport

   Such a representation would result in the URI being decomposed into
   its constituent components, with the CoAP resource residing within
   the query component as follows:

   Scheme: coap-at

   Path: tcp://example.com




Silverajan & Savolainen  Expires January 4, 2018               [Page 12]


Internet-Draft         CoAP Alternative Transports             July 2017


   Query: coap://example.com/sensors/temperature

   The same CoAP resource, if requested over a WebSocket transport,
   would result the following URI:



   coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature
           \___________  __________/ \_______________  ___________________/
                       \/                            \/
               Transport-specific             CoAP Resource
                     Prefix



          Figure 4: Prefixing a CoAP URI with WebSocket transport

   While the transport prefix changes, the CoAP resource representation
   remains the same in the query component:

   Scheme: coap-at

   Path: ws://example.com/endpoint

   Query: coap://example.com/sensors/temperature

   The URI format described here overcomes URI aliasing [WWWArchv1] when
   multiple transports are used, by ensuring each CoAP resource
   representation remains the same, but is prefixed with different
   transports.  However, against a base URI of this format, resolving
   relative references of the form "//example.net/sensors/temperature"
   and "/sensor2/temperature" would again result in target URIs which
   lose transport-specific information.

   Implementation note: While square brackets are disallowed within the
   path component, the '[' and ']' characters needed to enclose a
   literal IPv6 address can be percent-encoded into their respective
   equivalents.  The ':' character does not need to be percent-encoded.
   This results in a significantly simpler URI string compared to
   section 2.2, particularly for compressed IPv6 addresses.
   Additionally, the URI format can be used to specify other similar
   address families and formats, such as Bluetooth addresses.

A.3.  Transport as part of a 'service:' URL scheme

   The "service:" URL scheme name was introduced in [RFC2609] and forms
   the basis of service description used primarily by the Service
   Location Protocol.  An abstract service type URI would have the form



Silverajan & Savolainen  Expires January 4, 2018               [Page 13]


Internet-Draft         CoAP Alternative Transports             July 2017


   "service:<abstract-type>:<concrete-type>"

   where <abstract-type> refers to a service type name that can be
   associated with a variety of protocols, while the <concrete-type>
   then providing the specific details of the protocol used, authority
   and other URI components.

   Adopting the "service:" URL scheme to describe CoAP usage over
   alternative transports would be rather trivial.  To use a previous
   example, a CoAP service to discover a Resource Directory and its base
   RD resource using TCP would take the form

   service:coap:tcp://host.example.com/.well-known/core?rt=core-rd

   The syntax of the "service:" URL scheme differs from the generic URI
   syntax and therefore such a representation should be treated as an
   opaque URI as Section 2.1 of [RFC2609] recommends.

Authors' Addresses

   Bilhanan Silverajan
   Tampere University of Technology
   Korkeakoulunkatu 10
   FI-33720 Tampere
   Finland

   Email: bilhanan.silverajan@tut.fi


   Teemu Savolainen
   Nokia Technologies
   Hatanpaeaen valtatie 30
   FI-33100 Tampere
   Finland

   Email: teemu.savolainen@nokia.com















Silverajan & Savolainen  Expires January 4, 2018               [Page 14]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/