idnits 2.17.1 draft-amsuess-core-coap-kitchensink-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(319): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 March 2022) is 786 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7252' is defined on line 283, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-11 -- Obsolete informational reference (is this intentional?): RFC 132 (Obsoleted by RFC 154) == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-16 == Outdated reference: A later version (-04) exists of draft-lenders-dns-over-coap-02 == Outdated reference: A later version (-02) exists of draft-ietf-core-fasor-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 2 March 2022 4 Intended status: Informational 5 Expires: 3 September 2022 7 Everything over CoAP 8 draft-amsuess-core-coap-kitchensink-00 10 Abstract 12 The Constrained Application Protocol (CoAP) has become the base of 13 applications both inside of the constrained devices space it 14 originally aimed for and outside. This document gives an overview of 15 applications that are, can, may, and would better not be implemented 16 on top of CoAP. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the Constrained RESTful 23 Environments Working Group mailing list (core@ietf.org), which is 24 archived at https://mailarchive.ietf.org/arch/browse/core/. 26 Source for this draft and an issue tracker can be found at 27 https://gitlab.com/chrysn/coap-kitchensink. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 3 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2.1. Publish-Subscribe services . . . . . . . . . . . . . . . 2 65 2.2. Remote configuration . . . . . . . . . . . . . . . . . . 3 66 2.2.1. Network status monitoring . . . . . . . . . . . . . . 3 67 2.3. Software updates . . . . . . . . . . . . . . . . . . . . 4 68 2.4. Network file system . . . . . . . . . . . . . . . . . . . 4 69 2.5. Network address resolution . . . . . . . . . . . . . . . 4 70 2.6. Time service . . . . . . . . . . . . . . . . . . . . . . 5 71 2.7. Terminal access . . . . . . . . . . . . . . . . . . . . . 5 72 2.8. Chat services . . . . . . . . . . . . . . . . . . . . . . 6 73 2.9. E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.10. Video streaming . . . . . . . . . . . . . . . . . . . . . 6 75 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 3.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Appendix A. CoAP . . . . . . . . . . . . . . . . . . . . . . . . 8 79 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 [ See abstract for now ] 86 2. Applications 88 2.1. Publish-Subscribe services 90 Publish-subscribe services (pubsub) are a widespread tool for the 91 some of the fundamental use cases of Internet of Things (IoT) 92 protocols: acquiring sensor data and controlling actuators. 94 A pubsub implementation has been in development since shorlty after 95 the original CoAP publication and is as of now still in draft status, 96 as [I-D.ietf-core-coap-pubsub]. 98 Competing with MQTT 100 Strong points Once a topic is set up, data can be sent and received 101 by CoAP clients that are not even aware of pubsub, as long as they 102 can PUT or GET (possibly with observation) data to and from 103 configured URIs. 105 Weak points To implement a pubsub broker that supports arbitrarily 106 many topics, some (potentially difficult-to-implement) compromises 107 have to be made. 109 2.2. Remote configuration 111 The OMA LwM2M protocol (which caters for several applications at the 112 granularity of this document) includes provisions for configuring and 113 monitoring devices over the network, setting properties such as a 114 time server and reading properties such as a network interface's 115 packet count. 117 In parallel, the NETCONF protocol and its YANG modelling language 118 have been ported to the constrained ecosystem as CORECONF 119 [I-D.ietf-core-comi]. By using numeric identifiers with good 120 compression properties, it can efficiently express data both from 121 shared and from bespoke models in single requests. 123 Competing with SNMP [ ? ], Puppet [ ? ] 125 2.2.1. Network status monitoring 127 Related to remote configuration, CoAP is used as the signalling 128 channel of DOTS ([RFC132]). 130 Strong points CoAP over UDP/DTLS provides operational signalling on 131 links under attack, on which a TCP/TLS based connection would 132 fail. 134 CoAP's consistency across transports makes it easy to adjust to 135 situations in which UDP is uanvailable, sacrificing some 136 properties but leaving the high-level protocol unmodified. 138 Weak points CoAP's default parameters for flow control (such as 139 PROBING_RATE) are unsuitable for this application and need to be 140 customized. 142 2.3. Software updates 144 The SUIT manifest format [I-D.ietf-suit-manifest] can be used to 145 describe firmware updates that can be performed over CoAP or any 146 other protocol that is expressible in terms of URIs. 148 The OMA LwM2M protocol also contains provisions for firmware updates 149 over CoAP. 151 2.4. Network file system 153 Using CoAP as a backend for a no-frills file service is a simple 154 composition and is provided as a demo by the aiocoap library. 156 It has never been specified and described; that gap is closed in 157 Appendix A. 159 Competing with WebDAV, NFS, FTP 161 Strong points CoAP protocol already provides random read access 162 (through the Block2 option), optimistic locking and cache (through 163 the ETag and If-Match options) and change notification (through 164 the Observe option). 166 Files can be used in other CoAP protocols without the client's 167 awareness (e.g. for SUIT) 169 Weak points Transfer of large files is inefficient due to the 170 repetition of file names in block-wise requests (mitigated when 171 using CoAP-over-TCP and BERT). 173 Advanced file system functionality (file metadata, server-to- 174 server copies, renaming, locking) would need additional 175 specifications. 177 2.5. Network address resolution 179 The Domain Name System (DNS) can be utilized from CoAP using the 180 mechanisms described in [I-D.draft-lenders-dns-over-coap]. 182 Strong points Savings in firmware complexity by using infrastructure 183 shared with other applications. 185 Potential for traffic (and thus energy) reduction by using 186 request-response binding. 188 Weak points Not deployed in existing networks. 190 2.6. Time service 192 Whereas no attempt has been made yet to specify a time service over 193 CoAP, a primitive time service can be assembled by creating a CoAP 194 resource that returns the server's current time, e.g., in a UNIX time 195 stamp represented in decimal ASCII, or in CBOR using any of timestamp 196 tags (0, 1 or 1001). 198 Such services have been in use since at least 2013, and are easy to 199 operate and scale. 201 Competing with SNTP, NTP 203 Strong points Savings in firmware complexity by using infrastructure 204 shared with other applications. 206 Compact messages. 208 Reuse of existing security associations. 210 Weak points None of the advanced features of (S)NTP, such as 211 distinction between receive and transmit timestamps. Not even 212 leap seconds are advertised (but that can be mitigated by using a 213 time scale that is not affected by them, such as TAI). 215 Generally only suitable for the last hop in time synchronization. 217 2.7. Terminal access 219 Virtual terminal access was one of the first network applications 220 described in an RFC ([RFC15]), and popular to date. 222 There is no full specification yet as to how to express the data 223 streams of character based user input and character based text 224 responses in CoAP. Necessary components, as well as optional future 225 extensions, have been sketched for the RIOT operating system at 226 https://forum.riot-os.org/t/coap-remote-shell/3340/5 227 (https://forum.riot-os.org/t/coap-remote-shell/3340/5). Unlike SSH, 228 that sketch assumes the presence of a single virtual terminal (as 229 opposed to one created per connection). On platforms with dynamic 230 resources and per-process output capture, an SSH-like muliplexing can 231 be created based on the resource collection pattern described in 232 [I-D.ietf-core-interfaces]. 234 Competing with SSH 236 Strong points The head-of-line blocking that occasionally plagues 237 TCP based connections is eliminiated in favor of on-demand 238 recovery (i.e., observing the last output will produce the latest 239 chunk of output, and the terminal may recover skipped data later 240 if it is still in the device's back-scroll buffer). 242 Weak points The default retransmission characteristics of CoAP make 243 operations painfully slow when encountering packet loss. Tuning 244 of parameters or the implementation of advanced flow control as 245 described in [I-D.ietf-core-fasor] are necessary for smooth 246 operation. 248 On-demand recovery is incompatible with regular terminals, and 249 requires either fully managed terminals (where the full output is 250 reprinted when lost fragments are recovered) or accepting the loss 251 of data where printed exceeding the network speed. (Data is still 252 lost gracefully, as the loss is detected and can be indicated 253 visually). 255 2.8. Chat services 257 The CoMatrix project https://comatrix.eu/ (https://comatrix.eu/) has 258 demonstrated that the Matrix chat protocol can be simplified to the 259 point where it becomes usable transparently with constrained devices. 261 2.9. E-Mail 263 While E-Mail was part of the considerations that led to the 264 definition of the Proxy-Uri option (which would technically allow a 265 cross-proxy to accept POST requests to, say, 266 mailto:office@example.com?subject=Sensor%20failure), no attempts are 267 known to send or receive E-Mail over CoAP. 269 2.10. Video streaming 271 The use of CoAP for real time video streaming and telemetry from 272 Unmanned Aerial Vehicles (UAVs) has been explored in 273 [I-D.bhattacharyya-core-a-realist]. 275 It is unclear whether CoAP could actually outperform unconstrained 276 streaming protocols such as WebRTC, or whether devices that produce 277 and consume video benefit from the constraints of CoAP. 279 3. References 281 3.1. Normative References 283 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 284 Application Protocol (CoAP)", RFC 7252, 285 DOI 10.17487/RFC7252, June 2014, 286 . 288 3.2. Informative References 290 [I-D.ietf-core-coap-pubsub] 291 Koster, M., Keranen, A., and J. Jimenez, "Publish- 292 Subscribe Broker for the Constrained Application Protocol 293 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 294 core-coap-pubsub-09, 30 September 2019, 295 . 298 [I-D.ietf-core-comi] 299 Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and 300 I. Petrov, "CoAP Management Interface (CORECONF)", Work in 301 Progress, Internet-Draft, draft-ietf-core-comi-11, 17 302 January 2021, . 305 [RFC132] White, J., "Typographical Error in RFC 107", RFC 132, 306 DOI 10.17487/RFC0132, April 1971, 307 . 309 [I-D.ietf-suit-manifest] 310 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 311 "A Concise Binary Object Representation (CBOR)-based 312 Serialization Format for the Software Updates for Internet 313 of Things (SUIT) Manifest", Work in Progress, Internet- 314 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 315 . 318 [I-D.draft-lenders-dns-over-coap] 319 Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C., 320 and M. Wählisch, "DNS Queries over CoAP (DoC)", Work in 321 Progress, Internet-Draft, draft-lenders-dns-over-coap-02, 322 25 October 2021, . 325 [RFC15] Carr, C., "Network subsystem for time sharing hosts", 326 RFC 15, DOI 10.17487/RFC0015, September 1969, 327 . 329 [I-D.ietf-core-interfaces] 330 Shelby, Z., Koster, M., Groves, C., Zhu, J., and B. 331 Silverajan, "Reusable Interface Definitions for 332 Constrained RESTful Environments", Work in Progress, 333 Internet-Draft, draft-ietf-core-interfaces-14, 11 March 334 2019, . 337 [I-D.ietf-core-fasor] 338 Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast- 339 Slow Retransmission Timeout and Congestion Control 340 Algorithm for CoAP", Work in Progress, Internet-Draft, 341 draft-ietf-core-fasor-01, 19 October 2020, 342 . 345 [I-D.bhattacharyya-core-a-realist] 346 Bhattacharyya, A., Agrawal, S., Rath, H., Pal, A., and B. 347 Purushothaman, "Adaptive RESTful Real-time Live Streaming 348 for Things (A-REaLiST)", Work in Progress, Internet-Draft, 349 draft-bhattacharyya-core-a-realist-02, 5 February 2019, 350 . 353 Appendix A. CoAP 355 This sketches [ TBD: describes ] a file transfer protocol / remote 356 file system built on top of CoAP. 358 A file server works similar to a WebDAV server, and follows these 359 rules (which are sometimes expressed from the point of view of the 360 server, but apply when a client maps them back into a file system in 361 such a way that operations can round-trip): 363 * Directories are unconditionally represented by URIs with a 364 trailing slash; files by those without one. 366 The GET operation is used to list them (for there is no PROPFIND 367 operation in CoAP). Different media types migth be used depending 368 on the capabilities of the parties, with application/link-format 369 as a base line. 371 (Note that application/link-format is not particularly efficient 372 for this purpose, as the directory listing needs to repeat the 373 requested resource's full path for each entry). 375 * Paths are constructed by placing directory names and either an 376 empty string (for the trailing slash) or the unescaped file name 377 in Uri-Path options. 379 * Clients may attempt to treat any URI composed of the file server 380 entry URI and additional path segments as files on the file 381 server. Consequently, any additional services the file server may 382 provide (e.g., as resources specified in extensions) are 383 necessarily assigned URIs with a query, for these can not be 384 inadvertedly constructed in an attempt to access a file. 386 * For lack of a HEAD option, file metadata can only be obtained by 387 performing a GET on the directory containing the file, or a FETCH 388 for efficiency if suitable media types are defined. 390 All metadata is provided on a best-effort basis, and the supported 391 directory formats limit what can be expressed. Typical supported 392 metadata are the media type (expressed as ct in link format) and 393 the size (sz). 395 * If write support is available and permissions allow, a client can 396 create files by performing a PUT operation on a previously 397 nonexistent resource. 399 Files can be overwritten by PUTting a new representation. Files 400 sent with block-wise transfer should be processed atomically by 401 the server unless explicitly negotiated otherwise. (On POSIX file 402 systems, this can be implemented without additional state by 403 storing the blocks in a temporary file whose name contains the 404 original file name and the block key of the request, and renaming 405 it to the target name when receiving the last block). 407 * Files and directories can be removed using the DELETE operation, 408 subject ot the same conditions as writing to resources. 410 Deleting directories is recursive; client that desire POSIX 411 semantics need to check whether the directory is empty and use the 412 If-Match option with the empty directory's ETag to avoid race 413 conditions. 415 * Regular CoAP extensions apply if the parties support them, for 416 example: 418 - Observation can be used to watch files or directories for 419 changes. 421 - ETags (e.g. derived from the file's stats) can be used to 422 ensure that large files are assembled correctly by the client, 423 and to perform file updates with optimistic locking by using 424 the If-Match option. 426 * Additional features can be specified and advertised separately, 427 either per resoource or by a named specification that provides 428 templates for further operations. 430 For example, a specification might say that when a file system is 431 advertised with a given interface (if parameter of link format), 432 for each file and directory there is an associated resource at 433 ?acl that describes access control applicable to that file, and 434 can be used with GET and PUT as per the ACL's policies. 436 Additional operations can use their custom media types and 437 methods, and possibly create more resources. For example, a 438 server-to-server copy (again, advertised by a suitable interface 439 parameter) could provide a ?copy resource under any directory, to 440 which a CBOR list containing two CRIs (source and destination) 441 would be posted. That specification might describe that if copies 442 are not completed instantly, the response might indicate a new 443 location using Uri-Path and Uri-Query options (the latter might be 444 necessary to not conflict with existing files) which tracks the 445 status of the operation. 447 Appendix B. Change log 449 (Initial version) 451 Author's Address 453 Christian Amsüss 454 Austria 455 Email: christian@amsuess.com