CoRE                                                           C. Amsüss
Internet-Draft                                              2 March 2022
Intended status: Informational
Expires: 3 September 2022

                          Everything over CoAP


   The Constrained Application Protocol (CoAP) has become the base of
   applications both inside of the constrained devices space it
   originally aimed for and outside.  This document gives an overview of
   applications that are, can, may, and would better not be implemented
   on top of CoAP.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Constrained RESTful
   Environments Working Group mailing list (, which is
   archived at

   Source for this draft and an issue tracker can be found at

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

   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 3 September 2022.

Amsüss                  Expires 3 September 2022                [Page 1]

Internet-Draft            Everything over CoAP                March 2022

Copyright Notice

   Copyright (c) 2022 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 (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Publish-Subscribe services  . . . . . . . . . . . . . . .   2
     2.2.  Remote configuration  . . . . . . . . . . . . . . . . . .   3
       2.2.1.  Network status monitoring . . . . . . . . . . . . . .   3
     2.3.  Software updates  . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Network file system . . . . . . . . . . . . . . . . . . .   4
     2.5.  Network address resolution  . . . . . . . . . . . . . . .   4
     2.6.  Time service  . . . . . . . . . . . . . . . . . . . . . .   5
     2.7.  Terminal access . . . . . . . . . . . . . . . . . . . . .   5
     2.8.  Chat services . . . . . . . . . . . . . . . . . . . . . .   6
     2.9.  E-Mail  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.10. Video streaming . . . . . . . . . . . . . . . . . . . . .   6
   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     3.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  CoAP . . . . . . . . . . . . . . . . . . . . . . . .   8
   Appendix B.  Change log . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [ See abstract for now ]

2.  Applications

2.1.  Publish-Subscribe services

   Publish-subscribe services (pubsub) are a widespread tool for the
   some of the fundamental use cases of Internet of Things (IoT)
   protocols: acquiring sensor data and controlling actuators.

Amsüss                  Expires 3 September 2022                [Page 2]

Internet-Draft            Everything over CoAP                March 2022

   A pubsub implementation has been in development since shorlty after
   the original CoAP publication and is as of now still in draft status,
   as [I-D.ietf-core-coap-pubsub].

   Competing with  MQTT

   Strong points  Once a topic is set up, data can be sent and received
      by CoAP clients that are not even aware of pubsub, as long as they
      can PUT or GET (possibly with observation) data to and from
      configured URIs.

   Weak points  To implement a pubsub broker that supports arbitrarily
      many topics, some (potentially difficult-to-implement) compromises
      have to be made.

2.2.  Remote configuration

   The OMA LwM2M protocol (which caters for several applications at the
   granularity of this document) includes provisions for configuring and
   monitoring devices over the network, setting properties such as a
   time server and reading properties such as a network interface's
   packet count.

   In parallel, the NETCONF protocol and its YANG modelling language
   have been ported to the constrained ecosystem as CORECONF
   [I-D.ietf-core-comi].  By using numeric identifiers with good
   compression properties, it can efficiently express data both from
   shared and from bespoke models in single requests.

   Competing with  SNMP [ ? ], Puppet [ ? ]

2.2.1.  Network status monitoring

   Related to remote configuration, CoAP is used as the signalling
   channel of DOTS ([RFC132]).

   Strong points  CoAP over UDP/DTLS provides operational signalling on
      links under attack, on which a TCP/TLS based connection would

      CoAP's consistency across transports makes it easy to adjust to
      situations in which UDP is uanvailable, sacrificing some
      properties but leaving the high-level protocol unmodified.

   Weak points  CoAP's default parameters for flow control (such as
      PROBING_RATE) are unsuitable for this application and need to be

Amsüss                  Expires 3 September 2022                [Page 3]

Internet-Draft            Everything over CoAP                March 2022

2.3.  Software updates

   The SUIT manifest format [I-D.ietf-suit-manifest] can be used to
   describe firmware updates that can be performed over CoAP or any
   other protocol that is expressible in terms of URIs.

   The OMA LwM2M protocol also contains provisions for firmware updates
   over CoAP.

2.4.  Network file system

   Using CoAP as a backend for a no-frills file service is a simple
   composition and is provided as a demo by the aiocoap library.

   It has never been specified and described; that gap is closed in
   Appendix A.

   Competing with  WebDAV, NFS, FTP

   Strong points  CoAP protocol already provides random read access
      (through the Block2 option), optimistic locking and cache (through
      the ETag and If-Match options) and change notification (through
      the Observe option).

      Files can be used in other CoAP protocols without the client's
      awareness (e.g. for SUIT)

   Weak points  Transfer of large files is inefficient due to the
      repetition of file names in block-wise requests (mitigated when
      using CoAP-over-TCP and BERT).

      Advanced file system functionality (file metadata, server-to-
      server copies, renaming, locking) would need additional

2.5.  Network address resolution

   The Domain Name System (DNS) can be utilized from CoAP using the
   mechanisms described in [I-D.draft-lenders-dns-over-coap].

   Strong points  Savings in firmware complexity by using infrastructure
      shared with other applications.

      Potential for traffic (and thus energy) reduction by using
      request-response binding.

   Weak points  Not deployed in existing networks.

Amsüss                  Expires 3 September 2022                [Page 4]

Internet-Draft            Everything over CoAP                March 2022

2.6.  Time service

   Whereas no attempt has been made yet to specify a time service over
   CoAP, a primitive time service can be assembled by creating a CoAP
   resource that returns the server's current time, e.g., in a UNIX time
   stamp represented in decimal ASCII, or in CBOR using any of timestamp
   tags (0, 1 or 1001).

   Such services have been in use since at least 2013, and are easy to
   operate and scale.

   Competing with  SNTP, NTP

   Strong points  Savings in firmware complexity by using infrastructure
      shared with other applications.

      Compact messages.

      Reuse of existing security associations.

   Weak points  None of the advanced features of (S)NTP, such as
      distinction between receive and transmit timestamps.  Not even
      leap seconds are advertised (but that can be mitigated by using a
      time scale that is not affected by them, such as TAI).

      Generally only suitable for the last hop in time synchronization.

2.7.  Terminal access

   Virtual terminal access was one of the first network applications
   described in an RFC ([RFC15]), and popular to date.

   There is no full specification yet as to how to express the data
   streams of character based user input and character based text
   responses in CoAP.  Necessary components, as well as optional future
   extensions, have been sketched for the RIOT operating system at
   (  Unlike SSH,
   that sketch assumes the presence of a single virtual terminal (as
   opposed to one created per connection).  On platforms with dynamic
   resources and per-process output capture, an SSH-like muliplexing can
   be created based on the resource collection pattern described in

   Competing with  SSH

   Strong points  The head-of-line blocking that occasionally plagues

Amsüss                  Expires 3 September 2022                [Page 5]

Internet-Draft            Everything over CoAP                March 2022

      TCP based connections is eliminiated in favor of on-demand
      recovery (i.e., observing the last output will produce the latest
      chunk of output, and the terminal may recover skipped data later
      if it is still in the device's back-scroll buffer).

   Weak points  The default retransmission characteristics of CoAP make
      operations painfully slow when encountering packet loss.  Tuning
      of parameters or the implementation of advanced flow control as
      described in [I-D.ietf-core-fasor] are necessary for smooth

      On-demand recovery is incompatible with regular terminals, and
      requires either fully managed terminals (where the full output is
      reprinted when lost fragments are recovered) or accepting the loss
      of data where printed exceeding the network speed.  (Data is still
      lost gracefully, as the loss is detected and can be indicated

2.8.  Chat services

   The CoMatrix project ( has
   demonstrated that the Matrix chat protocol can be simplified to the
   point where it becomes usable transparently with constrained devices.

2.9.  E-Mail

   While E-Mail was part of the considerations that led to the
   definition of the Proxy-Uri option (which would technically allow a
   cross-proxy to accept POST requests to, say,, no attempts are
   known to send or receive E-Mail over CoAP.

2.10.  Video streaming

   The use of CoAP for real time video streaming and telemetry from
   Unmanned Aerial Vehicles (UAVs) has been explored in

   It is unclear whether CoAP could actually outperform unconstrained
   streaming protocols such as WebRTC, or whether devices that produce
   and consume video benefit from the constraints of CoAP.

3.  References

3.1.  Normative References

Amsüss                  Expires 3 September 2022                [Page 6]

Internet-Draft            Everything over CoAP                March 2022

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

3.2.  Informative References

              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
              core-coap-pubsub-09, 30 September 2019,

              Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
              I. Petrov, "CoAP Management Interface (CORECONF)", Work in
              Progress, Internet-Draft, draft-ietf-core-comi-11, 17
              January 2021, <

   [RFC132]   White, J., "Typographical Error in RFC 107", RFC 132,
              DOI 10.17487/RFC0132, April 1971,

              Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
              "A Concise Binary Object Representation (CBOR)-based
              Serialization Format for the Software Updates for Internet
              of Things (SUIT) Manifest", Work in Progress, Internet-
              Draft, draft-ietf-suit-manifest-16, 25 October 2021,

              Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
              and M. Wählisch, "DNS Queries over CoAP (DoC)", Work in
              Progress, Internet-Draft, draft-lenders-dns-over-coap-02,
              25 October 2021, <

   [RFC15]    Carr, C., "Network subsystem for time sharing hosts",
              RFC 15, DOI 10.17487/RFC0015, September 1969,

Amsüss                  Expires 3 September 2022                [Page 7]

Internet-Draft            Everything over CoAP                March 2022

              Shelby, Z., Koster, M., Groves, C., Zhu, J., and B.
              Silverajan, "Reusable Interface Definitions for
              Constrained RESTful Environments", Work in Progress,
              Internet-Draft, draft-ietf-core-interfaces-14, 11 March
              2019, <

              Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast-
              Slow Retransmission Timeout and Congestion Control
              Algorithm for CoAP", Work in Progress, Internet-Draft,
              draft-ietf-core-fasor-01, 19 October 2020,

              Bhattacharyya, A., Agrawal, S., Rath, H., Pal, A., and B.
              Purushothaman, "Adaptive RESTful Real-time Live Streaming
              for Things (A-REaLiST)", Work in Progress, Internet-Draft,
              draft-bhattacharyya-core-a-realist-02, 5 February 2019,

Appendix A.  CoAP

   This sketches [ TBD: describes ] a file transfer protocol / remote
   file system built on top of CoAP.

   A file server works similar to a WebDAV server, and follows these
   rules (which are sometimes expressed from the point of view of the
   server, but apply when a client maps them back into a file system in
   such a way that operations can round-trip):

   *  Directories are unconditionally represented by URIs with a
      trailing slash; files by those without one.

      The GET operation is used to list them (for there is no PROPFIND
      operation in CoAP).  Different media types migth be used depending
      on the capabilities of the parties, with application/link-format
      as a base line.

      (Note that application/link-format is not particularly efficient
      for this purpose, as the directory listing needs to repeat the
      requested resource's full path for each entry).

Amsüss                  Expires 3 September 2022                [Page 8]

Internet-Draft            Everything over CoAP                March 2022

   *  Paths are constructed by placing directory names and either an
      empty string (for the trailing slash) or the unescaped file name
      in Uri-Path options.

   *  Clients may attempt to treat any URI composed of the file server
      entry URI and additional path segments as files on the file
      server.  Consequently, any additional services the file server may
      provide (e.g., as resources specified in extensions) are
      necessarily assigned URIs with a query, for these can not be
      inadvertedly constructed in an attempt to access a file.

   *  For lack of a HEAD option, file metadata can only be obtained by
      performing a GET on the directory containing the file, or a FETCH
      for efficiency if suitable media types are defined.

      All metadata is provided on a best-effort basis, and the supported
      directory formats limit what can be expressed.  Typical supported
      metadata are the media type (expressed as ct in link format) and
      the size (sz).

   *  If write support is available and permissions allow, a client can
      create files by performing a PUT operation on a previously
      nonexistent resource.

      Files can be overwritten by PUTting a new representation.  Files
      sent with block-wise transfer should be processed atomically by
      the server unless explicitly negotiated otherwise.  (On POSIX file
      systems, this can be implemented without additional state by
      storing the blocks in a temporary file whose name contains the
      original file name and the block key of the request, and renaming
      it to the target name when receiving the last block).

   *  Files and directories can be removed using the DELETE operation,
      subject ot the same conditions as writing to resources.

      Deleting directories is recursive; client that desire POSIX
      semantics need to check whether the directory is empty and use the
      If-Match option with the empty directory's ETag to avoid race

   *  Regular CoAP extensions apply if the parties support them, for

      -  Observation can be used to watch files or directories for

Amsüss                  Expires 3 September 2022                [Page 9]

Internet-Draft            Everything over CoAP                March 2022

      -  ETags (e.g. derived from the file's stats) can be used to
         ensure that large files are assembled correctly by the client,
         and to perform file updates with optimistic locking by using
         the If-Match option.

   *  Additional features can be specified and advertised separately,
      either per resoource or by a named specification that provides
      templates for further operations.

      For example, a specification might say that when a file system is
      advertised with a given interface (if parameter of link format),
      for each file and directory there is an associated resource at
      ?acl that describes access control applicable to that file, and
      can be used with GET and PUT as per the ACL's policies.

      Additional operations can use their custom media types and
      methods, and possibly create more resources.  For example, a
      server-to-server copy (again, advertised by a suitable interface
      parameter) could provide a ?copy resource under any directory, to
      which a CBOR list containing two CRIs (source and destination)
      would be posted.  That specification might describe that if copies
      are not completed instantly, the response might indicate a new
      location using Uri-Path and Uri-Query options (the latter might be
      necessary to not conflict with existing files) which tracks the
      status of the operation.

Appendix B.  Change log

   (Initial version)

Author's Address

   Christian Amsüss

Amsüss                  Expires 3 September 2022               [Page 10]