idnits 2.17.1 draft-irtf-t2trg-rest-iot-01.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 : ---------------------------------------------------------------------------- ** 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 == Line 390 has weird spacing: '... query frag...' -- The document date (May 04, 2018) is 2184 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 1062, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-12 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-13 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-04 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-14 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-14 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Informational M. Kovatsch 5 Expires: November 5, 2018 ETH Zurich 6 K. Hartke 7 Universitaet Bremen TZI 8 May 04, 2018 10 RESTful Design for Internet of Things Systems 11 draft-irtf-t2trg-rest-iot-01 13 Abstract 15 This document gives guidance for designing Internet of Things (IoT) 16 systems that follow the principles of the Representational State 17 Transfer (REST) architectural style. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 5, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. System design . . . . . . . . . . . . . . . . . . . . . . 8 58 3.3. Uniform Resource Identifiers (URIs) . . . . . . . . . . . 9 59 3.4. Representations . . . . . . . . . . . . . . . . . . . . . 10 60 3.5. HTTP/CoAP Methods . . . . . . . . . . . . . . . . . . . . 10 61 3.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 3.5.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.5.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.5.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.6. HTTP/CoAP Status/Response Codes . . . . . . . . . . . . . 12 66 4. REST Constraints . . . . . . . . . . . . . . . . . . . . . . 13 67 4.1. Client-Server . . . . . . . . . . . . . . . . . . . . . . 13 68 4.2. Stateless . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.3. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.4. Uniform Interface . . . . . . . . . . . . . . . . . . . . 14 71 4.5. Layered System . . . . . . . . . . . . . . . . . . . . . 15 72 4.6. Code-on-Demand . . . . . . . . . . . . . . . . . . . . . 15 73 5. Hypermedia-driven Applications . . . . . . . . . . . . . . . 16 74 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.2. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.3. Interaction . . . . . . . . . . . . . . . . . . . . . . . 18 77 5.4. Hypermedia-driven Design Guidance . . . . . . . . . . . . 18 78 6. Design Patterns . . . . . . . . . . . . . . . . . . . . . . . 18 79 6.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 19 80 6.2. Calling a Procedure . . . . . . . . . . . . . . . . . . . 19 81 6.2.1. Instantly Returning Procedures . . . . . . . . . . . 19 82 6.2.2. Long-running Procedures . . . . . . . . . . . . . . . 19 83 6.2.3. Conversion . . . . . . . . . . . . . . . . . . . . . 20 84 6.2.4. Events as State . . . . . . . . . . . . . . . . . . . 20 85 6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 87 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 9.2. Informative References . . . . . . . . . . . . . . . . . 25 91 Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 26 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 The Representational State Transfer (REST) architectural style [REST] 97 is a set of guidelines and best practices for building distributed 98 hypermedia systems. At its core is a set of constraints, which when 99 fulfilled enable desirable properties for distributed software 100 systems such as scalability and modifiability. When REST principles 101 are applied to the design of a system, the result is often called 102 RESTful and in particular an API following these principles is called 103 a RESTful API. 105 Different protocols can be used with RESTful systems, but at the time 106 of writing the most common protocols are HTTP [RFC7230] and CoAP 107 [RFC7252]. Since RESTful APIs are often simple and lightweight, they 108 are a good fit for various IoT applications. The goal of this 109 document is to give basic guidance for designing RESTful systems and 110 APIs for IoT applications and give pointers for more information. 111 Design of a good RESTful IoT system has naturally many commonalities 112 with other Web systems. Compared to other systems, the key 113 characteristics of many IoT systems include: 115 o data formats, interaction patterns, and other mechanisms that 116 minimize, or preferably avoid, the need for human interaction 118 o preference for compact and simple data formats to facilitate 119 efficient transfer over (often) constrained networks and 120 lightweight processing in constrained nodes 122 2. Terminology 124 This section explains some of the common terminology that is used in 125 the context of RESTful design for IoT systems. For terminology of 126 constrained nodes and networks, see [RFC7228]. 128 Cache: A local store of response messages and the subsystem that 129 controls storage, retrieval, and deletion of messages in it. 131 Client: A node that sends requests to servers and receives 132 responses. In RESTful IoT systems it's common for nodes to have 133 more than one role (e.g., both server and client; see 134 Section 3.1). 136 Client State: The state kept by a client between requests. This 137 typically includes the currently processed representation, the set 138 of active requests, the history of requests, bookmarks (URIs 139 stored for later retrieval), and application-specific state (e.g., 140 local variables). (Note that this is called "Application State" 141 in [REST], which has some ambiguity in modern (IoT) systems where 142 the overall state of the distributed application (i.e., 143 application state) is reflected in the union of all Client States 144 and Resource States of all clients and servers involved.) 146 Content Negotiation: The practice of determining the "best" 147 representation for a client when examining the current state of a 148 resource. The most common forms of content negotiation are 149 Proactive Content Negotiation and Reactive Content Negotiation. 151 Form: A hypermedia control that enables a client to change the state 152 of a resource or to construct a query locally. 154 Forward Proxy: An intermediary that is selected by a client, usually 155 via local configuration rules, and that can be tasked to make 156 requests on behalf of the client. This may be useful, for 157 example, when the client lacks the capability to make the request 158 itself or to service the response from a cache in order to reduce 159 response time, network bandwidth, and energy consumption. 161 Gateway: A reverse proxy that provides an interface to a non-RESTful 162 system such as legacy systems or alternative technologies such as 163 Bluetooth ATT/GATT. See also "Reverse Proxy". 165 Hypermedia Control: A component, such as a link or a form, embedded 166 in a representation that identifies a resource for future 167 hypermedia interactions. If the client engages in an interaction 168 with the identified resource, the result may be a change to 169 resource state and/or client state. 171 Idempotent Method: A method where multiple identical requests with 172 that method lead to the same visible resource state as a single 173 such request. 175 Link: A hypermedia control that enables a client to navigate between 176 resources and thereby change the client state. 178 Link Relation Type: An identifier that describes how the link target 179 resource relates to the current resource (see [RFC5988]). 181 Media Type: A string such as "text/html" or "application/json" that 182 is used to label representations so that it is known how the 183 representation should be interpreted and how it is encoded. 185 Method: An operation associated with a resource. Common methods 186 include GET, PUT, POST, and DELETE (see Section 3.5 for details). 188 Origin Server: A server that is the definitive source for 189 representations of its resources and the ultimate recipient of any 190 request that intends to modify its resources. In contrast, 191 intermediaries (such as proxies caching a representation) can 192 assume the role of a server, but are not the source for 193 representations as these are acquired from the origin server. 195 Proactive Content Negotiation: A content negotiation mechanism where 196 the server selects a representation based on the expressed 197 preference of the client. For example, an IoT application could 198 send a request to a sensor with preferred media type "application/ 199 senml+json". 201 Reactive Content Negotiation: A content negotiation mechanism where 202 the client selects a representation from a list of available 203 representations. The list may, for example, be included by a 204 server in an initial response. If the user agent is not satisfied 205 by the initial response representation, it can request one or more 206 of the alternative representations, selected based on metadata 207 (e.g., available media types) included in the response. 209 Representation: A serialization that represents the current or 210 intended state of a resource and that can be transferred between 211 clients and servers. REST requires representations to be self- 212 describing, meaning that there must be metadata that allows peers 213 to understand which representation format is used. Depending on 214 the protocol needs and capabilities, there can be additional 215 metadata that is transmitted along with the representation. 217 Representation Format: A set of rules for serializing resource 218 state. On the Web, the most prevalent representation format is 219 HTML. Other common formats include plain text and formats based 220 on JSON [RFC7159], XML, or RDF. Within IoT systems, often compact 221 formats based on JSON, CBOR [RFC7049], and EXI 222 [W3C.REC-exi-20110310] are used. 224 Representational State Transfer (REST): An architectural style for 225 Internet-scale distributed hypermedia systems. 227 Resource: An item of interest identified by a URI. Anything that 228 can be named can be a resource. A resource often encapsulates a 229 piece of state in a system. Typical resources in an IoT system 230 can be, e.g., a sensor, the current value of a sensor, the 231 location of a device, or the current state of an actuator. 233 Resource State: A model of a resource's possible states that is 234 represented in a supported representation type, typically a media 235 type. Resources can change state because of REST interactions 236 with them, or they can change state for reasons outside of the 237 REST model. 239 Resource Type: An identifier that annotates the application- 240 semantics of a resource (see Section 3.1 of [RFC6690]). 242 Reverse Proxy: An intermediary that appears as a server towards the 243 client but satisfies the requests by forwarding them to the actual 244 server (possibly via one or more other intermediaries). A reverse 245 proxy is often used to encapsulate legacy services, to improve 246 server performance through caching, and to enable load balancing 247 across multiple machines. 249 Safe Method: A method that does not result in any state change on 250 the origin server when applied to a resource. 252 Server: A node that listens for requests, performs the requested 253 operation and sends responses back to the clients. 255 Uniform Resource Identifier (URI): A global identifier for 256 resources. See Section 3.3 for more details. 258 3. Basics 260 3.1. Architecture 262 The components of a RESTful system are assigned one or both of two 263 roles: client or server. Note that the terms "client" and "server" 264 refer only to the roles that the nodes assume for a particular 265 message exchange. The same node might act as a client in some 266 communications and a server in others. Classic user agents (e.g., 267 Web browsers) are always in the client role and have the initiative 268 to issue requests. Origin servers always have the server role and 269 govern over the resources they host. 271 ________ _________ 272 | | | | 273 | User (C)-------------------(S) Origin | 274 | Agent | | Server | 275 |________| |_________| 276 (Browser) (Web Server) 278 Figure 1: Client-Server Communication 280 Intermediaries (such as forward proxies, reverse proxies, and 281 gateways) implement both roles, but only forward requests to other 282 intermediaries or origin servers. They can also translate requests 283 to different protocols, for instance, as CoAP-HTTP cross-proxies. 285 ________ __________ _________ 286 | | | | | | 287 | User (C)---(S) Inter- (C)--------------------(S) Origin | 288 | Agent | | mediary | | Server | 289 |________| |__________| |_________| 290 (Browser) (Forward Proxy) (Web Server) 292 Figure 2: Communication with Forward Proxy 294 Reverse proxies are usually imposed by the origin server. In 295 addition to the features of a forward proxy, they can also provide an 296 interface for non-RESTful services such as legacy systems or 297 alternative technologies such as Bluetooth ATT/GATT. In this case, 298 reverse proxies are usually called gateways. This property is 299 enabled by the Layered System constraint of REST, which says that a 300 client cannot see beyond the server it is connected to (i.e., it is 301 left unaware of the protocol/paradigm change). 303 ________ __________ _________ 304 | | | | | | 305 | User (C)--------------------(S) Inter- (x)---(x) Origin | 306 | Agent | | mediary | | Server | 307 |________| |__________| |_________| 308 (Browser) (Gateway) (Legacy System) 310 Figure 3: Communication with Reverse Proxy 312 Nodes in IoT systems often implement both roles. Unlike 313 intermediaries, however, they can take the initiative as a client 314 (e.g., to register with a directory, such as CoRE Resource Directory 315 [I-D.ietf-core-resource-directory], or to interact with another 316 thing) and act as origin server at the same time (e.g., to serve 317 sensor values or provide an actuator interface). 319 ________ _________ 320 | | | | 321 | Thing (C)-------------------------------------(S) Origin | 322 | (S) | Server | 323 |________| \ |_________| 324 (Sensor) \ ________ (Resource Directory) 325 \ | | 326 (C) Thing | 327 |________| 328 (Controller) 330 Figure 4: Constrained RESTful environments 332 3.2. System design 334 When designing a RESTful system, the primary effort goes into 335 modeling the state of the distributed application and assigning it to 336 the different components (i.e., clients and servers). How clients 337 can navigate through the resources and modify state to achieve their 338 goals is defined through hypermedia controls, that is, links and 339 forms. Hypermedia controls span a kind of a state machine where the 340 nodes are resources and the transitions are links or forms. Clients 341 run this state machine (i.e., the application) by retrieving 342 representations, processing the data, and following the included 343 hypermedia controls. In REST, remote state is changed by submitting 344 forms. This is usually done by retrieving the current state, 345 modifying the state on the client side, and transferring the new 346 state to the server in the form of new representations - rather than 347 calling a service and modifying the state on the server side. 349 Client state encompasses the current state of the described state 350 machine and the possible next transitions derived from the hypermedia 351 controls within the currently processed representation (see 352 Section 2). Furthermore, clients can have part of the state of the 353 distributed application in local variables. 355 Resource state includes the more persistent data of an application 356 (i.e., independent of individual clients). This can be static data 357 such as device descriptions, persistent data such as system 358 configurations, but also dynamic data such as the current value of a 359 sensor on a thing. 361 It is important to distinguish between "client state" and "resource 362 state" and keep them separate. Following the Stateless constraint, 363 the client state must be kept only on clients. That is, there is no 364 establishment of shared information about past and future 365 interactions between client and server (usually called a session). 366 On the one hand, this makes requests a bit more verbose since every 367 request must contain all the information necessary to process it. On 368 the other hand, this makes servers efficient and scalable, since they 369 do not have to keep any state about their clients. Requests can 370 easily be distributed over multiple worker threads or server 371 instances. For IoT systems, this constraint lowers the memory 372 requirements for server implementations, which is particularly 373 important for constrained servers (e.g., sensor nodes) and servers 374 serving large amount of clients (e.g., Resource Directory). 376 3.3. Uniform Resource Identifiers (URIs) 378 An important part of RESTful API design is to model the system as a 379 set of resources whose state can be retrieved and/or modified and 380 where resources can be potentially also created and/or deleted. 382 Uniform Resource Identifiers (URIs) are used to indicate a resource 383 for interaction, to reference a resource from another resource, to 384 advertise or bookmark a resource, or to index a resource by search 385 engines. 387 foo://example.com:8042/over/there?name=ferret#nose 388 \_/ \______________/\_________/ \_________/ \__/ 389 | | | | | 390 scheme authority path query fragment 392 A URI is a sequence of characters that matches the syntax defined in 393 [RFC3986]. It consists of a hierarchical sequence of five 394 components: scheme, authority, path, query, and fragment (from most 395 significant to least significant). A scheme creates a namespace for 396 resources and defines how the following components identify a 397 resource within that namespace. The authority identifies an entity 398 that governs part of the namespace, such as the server 399 "www.example.org" in the "http" scheme. A host name (e.g., a fully 400 qualified domain name) or an IP address, potentially followed by a 401 transport layer port number, are usually used in the authority 402 component for the "http" and "coap" schemes. The path and query 403 contain data to identify a resource within the scope of the URI's 404 scheme and naming authority. The fragment allows to refer to some 405 portion of the resource, such as a Record in a SenML Pack. However, 406 fragments are processed only at client side and not sent on the wire. 407 [RFC7320] provides more details on URI design and ownership with best 408 current practices for establishing URI structures, conventions, and 409 formats. 411 For RESTful IoT applications, typical schemes include "https", 412 "coaps", "http", and "coap". These refer to HTTP and CoAP, with and 413 without Transport Layer Security (TLS) [RFC5246]. (CoAP uses 414 Datagram TLS (DTLS) [RFC6347], the variant of TLS for UDP.) These 415 four schemes also provide means for locating the resource; using the 416 HTTP protocol for "http" and "https", and with the CoAP protocol for 417 "coap" and "coaps". If the scheme is different for two URIs (e.g., 418 "coap" vs. "coaps"), it is important to note that even if the rest of 419 the URI is identical, these are two different resources, in two 420 distinct namespaces. 422 The query parameters can be used to parametrize the resource. For 423 example, a GET request may use query parameters to request the server 424 to send only certain kind data of the resource (i.e., filtering the 425 response). Query parameters in PUT and POST requests do not have 426 such established semantics and are not commonly used. Whether the 427 order of the query parameters matters in URIs is unspecified and they 428 can be re-ordered e.g., by proxies. Therefore applications should 429 not rely on their order; see Section 3.3 of [RFC6943] for more 430 details. 432 3.4. Representations 434 Clients can retrieve the resource state from an origin server or 435 manipulate resource state on the origin server by transferring 436 resource representations. Resource representations have a media type 437 that tells how the representation should be interpreted by 438 identifying the representation format used. 440 Typical media types for IoT systems include: 442 o "text/plain" for simple UTF-8 text 444 o "application/octet-stream" for arbitrary binary data 446 o "application/json" for the JSON format [RFC7159] 448 o "application/senml+json" [I-D.ietf-core-senml] for Sensor Markup 449 Language (SenML) formatted data 451 o "application/cbor" for CBOR [RFC7049] 453 o "application/exi" for EXI [W3C.REC-exi-20110310] 455 A full list of registered Internet Media Types is available at the 456 IANA registry [IANA-media-types] and numerical media types registered 457 for use with CoAP are listed at CoAP Content-Formats IANA registry 458 [IANA-CoAP-media]. 460 3.5. HTTP/CoAP Methods 462 Section 4.3 of [RFC7231] defines the set of methods in HTTP; 463 Section 5.8 of [RFC7252] defines the set of methods in CoAP. As part 464 of the Uniform Interface constraint, each method can have certain 465 properties that give guarantees to clients. 467 Safe methods do not cause any state change on the origin server when 468 applied to a resource. For example, the GET method only returns a 469 representation of the resource state but does not change the 470 resource. Thus, it is always safe for a client to retrieve a 471 representation without affecting server-side state. 473 Idempotent methods can be applied multiple times to the same resource 474 while causing the same visible resource state as a single such 475 request. For example, the PUT method replaces the state of a 476 resource with a new state; replacing the state multiple times with 477 the same new state still results in the same state for the resource. 478 However, the response from the server can be different when the same 479 idempotent method is used multiple times. For example when DELETE is 480 used twice on an existing resource, the first request would remove 481 the association and return success acknowledgement whereas the second 482 request would likely result in error response due to non-existing 483 resource. 485 The following lists the most relevant methods and gives a short 486 explanation of their semantics. 488 3.5.1. GET 490 The GET method requests a current representation for the target 491 resource, while the origin server must ensure that there are no side- 492 effects on the resource state. Only the origin server needs to know 493 how each of its resource identifiers corresponds to an implementation 494 and how each implementation manages to select and send a current 495 representation of the target resource in a response to GET. 497 A payload within a GET request message has no defined semantics. 499 The GET method is safe and idempotent. 501 3.5.2. POST 503 The POST method requests that the target resource process the 504 representation enclosed in the request according to the resource's 505 own specific semantics. 507 If one or more resources has been created on the origin server as a 508 result of successfully processing a POST request, the origin server 509 sends a 201 (Created) response containing a Location header field 510 (with HTTP) or Location-Path and/or Location-Query Options (with 511 CoAP) that provide an identifier for the resource created. The 512 server also includes a representation that describes the status of 513 the request while referring to the new resource(s). 515 The POST method is not safe nor idempotent. 517 3.5.3. PUT 519 The PUT method requests that the state of the target resource be 520 created or replaced with the state defined by the representation 521 enclosed in the request message payload. A successful PUT of a given 522 representation would suggest that a subsequent GET on that same 523 target resource will result in an equivalent representation being 524 sent. 526 The fundamental difference between the POST and PUT methods is 527 highlighted by the different intent for the enclosed representation. 528 The target resource in a POST request is intended to handle the 529 enclosed representation according to the resource's own semantics, 530 whereas the enclosed representation in a PUT request is defined as 531 replacing the state of the target resource. Hence, the intent of PUT 532 is idempotent and visible to intermediaries, even though the exact 533 effect is only known by the origin server. 535 The PUT method is not safe, but is idempotent. 537 3.5.4. DELETE 539 The DELETE method requests that the origin server remove the 540 association between the target resource and its current 541 functionality. 543 If the target resource has one or more current representations, they 544 might or might not be destroyed by the origin server, and the 545 associated storage might or might not be reclaimed, depending 546 entirely on the nature of the resource and its implementation by the 547 origin server. 549 The DELETE method is not safe, but is idempotent. 551 3.6. HTTP/CoAP Status/Response Codes 553 Section 6 of [RFC7231] defines a set of Status Codes in HTTP that are 554 used by application to indicate whether a request was understood and 555 satisfied, and how to interpret the answer. Similarly, Section 5.9 556 of [RFC7252] defines the set of Response Codes in CoAP. 558 The status codes consist of three digits (e.g., "404" with HTTP or 559 "4.04" with CoAP) where the first digit expresses the class of the 560 code. Implementations do not need to understand all status codes, 561 but the class of the code must be understood. Codes starting with 1 562 are informational; the request was received and being processed. 563 Codes starting with 2 indicate a successful request. Codes starting 564 with 3 indicate redirection; further action is needed to complete the 565 request. Codes stating with 4 and 5 indicate errors. The codes 566 starting with 4 mean client error (e.g., bad syntax in the request) 567 whereas codes starting with 5 mean server error; there was no 568 apparent problem with the request, but server was not able to fulfill 569 the request. 571 Responses may be stored in a cache to satisfy future, equivalent 572 requests. HTTP and CoAP use two different patterns to decide what 573 responses are cacheable. In HTTP, the cacheability of a response 574 depends on the request method (e.g., responses returned in reply to a 575 GET request are cacheable). In CoAP, the cacheability of a response 576 depends on the response code (e.g., responses with code 2.04 are 577 cacheable). This difference also leads to slightly different 578 semantics for the codes starting with 2; for example, CoAP does not 579 have a 2.00 response code whereas 200 ("OK") is commonly used with 580 HTTP. 582 4. REST Constraints 584 The REST architectural style defines a set of constraints for the 585 system design. When all constraints are applied correctly, REST 586 enables architectural properties of key interest [REST]: 588 o Performance 590 o Scalability 592 o Reliability 594 o Simplicity 596 o Modifiability 598 o Visibility 600 o Portability 602 The following sub-sections briefly summarize the REST constraints and 603 explain how they enable the listed properties. 605 4.1. Client-Server 607 As explained in the Architecture section, RESTful system components 608 have clear roles in every interaction. Clients have the initiative 609 to issue requests, intermediaries can only forward requests, and 610 servers respond requests, while origin servers are the ultimate 611 recipient of requests that intent to modify resource state. 613 This improves simplicity and visibility, as it is clear which 614 component started an interaction. Furthermore, it improves 615 modifiability through a clear separation of concerns. 617 4.2. Stateless 619 The Stateless constraint requires messages to be self-contained. 620 They must contain all the information to process it, independent from 621 previous messages. This allows to strictly separate the client state 622 from the resource state. 624 This improves scalability and reliability, since servers or worker 625 threads can be replicated. It also improves visibility because 626 message traces contain all the information to understand the logged 627 interactions. 629 Furthermore, the Stateless constraint enables caching. 631 4.3. Cache 633 This constraint requires responses to have implicit or explicit 634 cache-control metadata. This enables clients and intermediary to 635 store responses and re-use them to locally answer future requests. 636 The cache-control metadata is necessary to decide whether the 637 information in the cached response is still fresh or stale and needs 638 to be discarded. 640 Cache improves performance, as less data needs to be transferred and 641 response times can be reduced significantly. Less transfers also 642 improves scalability, as origin servers can be protected from too 643 many requests. Local caches furthermore improve reliability, since 644 requests can be answered even if the origin server is temporarily not 645 available. 647 4.4. Uniform Interface 649 All RESTful APIs use the same, uniform interface independent of the 650 application. This simple interaction model is enabled by exchanging 651 representations and modifying state locally, which simplifies the 652 interface between clients and servers to a small set of methods to 653 retrieve, update, and delete state - which applies to all 654 applications. 656 In contrast, in a service-oriented RPC approach, all required ways to 657 modify state need to be modeled explicitly in the interface resulting 658 in a large set of methods - which differs from application to 659 application. Moreover, it is also likely that different parties come 660 up with different ways how to modify state, including the naming of 661 the procedures, while the state within an application is a bit easier 662 to agree on. 664 A REST interface is fully defined by: 666 o URIs to identify resources 668 o representation formats to represent (and retrieve and manipulate) 669 resource state 671 o self-descriptive messages with a standard set of methods (e.g., 672 GET, POST, PUT, DELETE with their guaranteed properties) 674 o hypermedia controls within representations 676 The concept of hypermedia controls is also known as HATEOAS: 677 Hypermedia As The Engine Of Application State. The origin server 678 embeds controls for the interface into its representations and 679 thereby informs the client about possible next requests. The mostly 680 used control for RESTful systems is Web Linking [RFC5590]. 681 Hypermedia forms are more powerful controls that describe how to 682 construct more complex requests, including representations to modify 683 resource state. 685 While this is the most complex constraints (in particular the 686 hypermedia controls), it improves many different key properties. It 687 improves simplicity, as uniform interfaces are easier to understand. 688 The self-descriptive messages improve visibility. The limitation to 689 a known set of representation formats fosters portability. Most of 690 all, however, this constraint is the key to modifiability, as 691 hypermedia-driven, uniform interfaces allow clients and servers to 692 evolve independently, and hence enable a system to evolve. 694 4.5. Layered System 696 This constraint enforces that a client cannot see beyond the server 697 with which it is interacting. 699 A layered system is easier to modify, as topology changes become 700 transparent. Furthermore, this helps scalability, as intermediaries 701 such as load balancers can be introduced without changing the client 702 side. The clean separation of concerns helps with simplicity. 704 4.6. Code-on-Demand 706 This principle enables origin servers to ship code to clients. 708 Code-on-Demand improves modifiability, since new features can be 709 deployed during runtime (e.g., support for a new representation 710 format). It also improves performance, as the server can provide 711 code for local pre-processing before transferring the data. 713 5. Hypermedia-driven Applications 715 Hypermedia-driven applications take advantage of hypermedia controls, 716 i.e., links and forms, embedded in the resource representations. A 717 hypermedia client is a client that is capable of processing these 718 hypermedia controls. Hypermedia links can be used to give additional 719 information about a resource representation (e.g., the source URI of 720 the representation) or pointing to other resources. The forms can be 721 used to describe the structure of the data that can be sent (e.g., 722 with a POST or PUT method) to a server, or how a data retrieval 723 (e.g., GET) request for a resource should be formed. In a 724 hypermedia-driven application the client interacts with the server 725 using only the hypermedia controls, instead of selecting methods and/ 726 or constructing URIs based on out-of-band information, such as API 727 documentation. 729 5.1. Motivation 731 The advantage of this approach is increased evolvability and 732 extensibility. This is important in scenarios where servers exhibit 733 a range of feature variations, where it's expensive to keep evolving 734 client knowledge and server knowledge in sync all the time, or where 735 there are many different client and server implementations. 736 Hypermedia controls serve as indicators in capability negotiation. 737 In particular, they describe available resources and possible 738 operations on these resources using links and forms, respectively. 740 There are multiple reasons why a server might introduce new links or 741 forms: 743 o The server implements a newer version of the application. Older 744 clients ignore the new links and forms, while newer clients are 745 able to take advantage of the new features by following the new 746 links and submitting the new forms. 748 o The server offers links and forms depending on the current state. 749 The server can tell the client which operations are currently 750 valid and thus help the client navigate the application state 751 machine. The client does not have to have knowledge which 752 operations are allowed in the current state or make a request just 753 to find out that the operation is not valid. 755 o The server offers links and forms depending on the client's access 756 control rights. If the client is unauthorized to perform a 757 certain operation, then the server can simply omit the links and 758 forms for that operation. 760 5.2. Knowledge 762 A client needs to have knowledge of a couple of things for successful 763 interaction with a server. This includes what resources are 764 available, what representations of resource states are available, 765 what each representation describes, how to retrieve a representation, 766 what state changing operations on a resource are possible, how to 767 perform these operations, and so on. 769 Some part of this knowledge, such as how to retrieve the 770 representation of a resource state, is typically hard-coded in the 771 client software. For other parts, a choice can often be made between 772 hard-coding the knowledge or acquiring it on-demand. The key to 773 success in either case is the use in-band information for identifying 774 the knowledge that is required. This enables the client to verify 775 that is has all required knowledge and to acquire missing knowledge 776 on-demand. 778 A hypermedia-driven application typically uses the following 779 identifiers: 781 o URI schemes that identify communication protocols, 783 o Internet Media Types that identify representation formats, 785 o link relation types or resource types that identify link 786 semantics, 788 o form relation types that identify form semantics, 790 o variable names that identify the semantics of variables in 791 templated links, and 793 o form field names that identify the semantics of form fields in 794 forms. 796 The knowledge about these identifiers as well as matching 797 implementations have to be shared a priori in a RESTful system. 799 5.3. Interaction 801 A client begins interacting with an application through a GET request 802 on an entry point URI. The entry point URI is the only URI a client 803 is expected to know before interacting with an application. From 804 there, the client is expected to make all requests by following links 805 and submitting forms that are provided in previous responses. The 806 entry point URI can be obtained, for example, by manual configuration 807 or some discovery process (e.g., DNS-SD [RFC6763] or Resource 808 Directory [I-D.ietf-core-resource-directory]). For Constrained 809 RESTful environments "/.well-known/core" relative URI is defined as a 810 default entry point for requesting the links hosted by servers with 811 known or discovered addresses [RFC6690]. 813 5.4. Hypermedia-driven Design Guidance 815 Assuming self-describing representation formats (i.e., human-readable 816 with carefully chosen terms or processible by a formatting tool) and 817 a client supporting the URI scheme used, a good rule of thumb for a 818 good hypermedia-driven design is the following: A developer should 819 only need an entry point URI to drive the application. All further 820 information how to navigate through the application (links) and how 821 to construct more complex requests (forms) are published by the 822 server(s). There must be no need for additional, out-of-band 823 information (e.g., API specification). 825 For machines, a well-chosen set of information needs to be shared a 826 priori to agree on machine-understandable semantics. Agreeing on the 827 exact semantics of terms for relation types and data elements will of 828 course also help the developer. 830 6. Design Patterns 832 Certain kinds of design problems are often recurring in variety of 833 domains, and often re-usable design patterns can be applied to them. 834 Also some interactions with a RESTful IoT system are straightforward 835 to design; a classic example of reading a temperature from a 836 thermometer device is almost always implemented as a GET request to a 837 resource that represents the current value of the thermometer. 838 However, certain interactions, for example data conversions or event 839 handling, do not have as straightforward and well established ways to 840 represent the logic with resources and REST methods. 842 The following sections describe how common design problems such as 843 different interactions can be modeled with REST and what are the 844 benefits of different approaches. 846 6.1. Collections 848 A common pattern in RESTful systems across different domains is the 849 collection. A collection can be used to combine multiple resources 850 together by providing resources that consist of set of (often 851 partial) representations of resources, called items, and links to 852 resources. The collection resource also defines hypermedia controls 853 for managing and searching the items in the collection. 855 Examples of the collection pattern in RESTful IoT systems are the 856 CoRE Resource Directory [I-D.ietf-core-resource-directory], CoAP pub/ 857 sub broker [I-D.ietf-core-coap-pubsub], and resource discovery via 858 ".well-known/core". Collection+JSON [CollectionJSON] is an example 859 of a generic collection Media Type. 861 6.2. Calling a Procedure 863 To modify resource state, clients usually use GET to retrieve a 864 representation from the server, modify that locally, and transfer the 865 resulting state back to the server with a PUT (see Section 4.4). 866 Sometimes, however, the state can only be modified on the server 867 side, for instance, because representations would be too large to 868 transfer or part of the required information shall not be accessible 869 to clients. In this case, resource state is modified by calling a 870 procedure (or "function"). This is usually modeled with a POST 871 request, as this method leaves the behavior semantics completely to 872 the server. Procedure calls can be divided into two different 873 classes based on how long they are expected to execute: "instantly" 874 returning and long-running. 876 6.2.1. Instantly Returning Procedures 878 When the procedure can return within the expected response time of 879 the system, the result can be directly returned in the response. The 880 result can either be actual content or just a confirmation that the 881 call was successful. In either case, the response does not contain a 882 representation of the resource, but a so-called action result. 883 Action results can still have hypermedia controls to provide the 884 possible transitions in the application state machine. 886 6.2.2. Long-running Procedures 888 When the procedure takes longer than the expected response time of 889 the system, or even longer than the response timeout, it is a good 890 pattern to create a new resource to track the "task" execution. The 891 server would respond instantly with a "Created" status (HTTP code 201 892 or CoAP 2.01) and indicate the location of the task resource in the 893 corresponding header field (or CoAP option) or as a link in the 894 action result. The created resource can be used to monitor the 895 progress, to potentially modify queued tasks or cancel tasks, and to 896 eventually retrieve the result. 898 Monitoring information would be modeled as state of the task 899 resource, and hence be retrievable as representation. The result - 900 when available - can be embedded in the representation or given as a 901 link to another sub-resource. Modifying tasks can be modeled with 902 forms that either update sub-resources via PUT or do a partial write 903 using PATCH or POST. Canceling a task would be modeled with a form 904 that uses DELETE to remove the task resource. 906 6.2.3. Conversion 908 A conversion service is a good example where REST resources need to 909 behave more like a procedure call. The knowledge of converting from 910 one representation to another is located only at the server to 911 relieve clients from high processing or storing lots of data. There 912 are different approaches that all depend on the particular conversion 913 problem. 915 As mentioned in the previous sections, POST request are a good way to 916 model functionality that does not necessarily affect resource state. 917 When the input data for the conversion is small and the conversion 918 result is deterministic, however, it can be better to use a GET 919 request with the input data in the URI query part. The query is 920 parameterizing the conversion resource, so that it acts like a look- 921 up table. The benefit is that results can be cached also for HTTP 922 (where responses to POST are not cacheable). In CoAP, cacheability 923 depends on the response code, so that also a response to a POST 924 request can be made cacheable through a 2.05 Content code. 926 When the input data is large or has a binary encoding, it is better 927 to use POST requests with a proper Media Type for the input 928 representation. A POST request is also more suitable, when the 929 result is time-dependent and the latest result is expected (e.g., 930 exchange rates). 932 6.2.4. Events as State 934 In event-centric paradigms such as pub/sub, events are usually 935 represented by an incoming message that might even be identical for 936 each occurrence. Since the messages are queued, the receiver is 937 aware of each occurrence of the event and can react accordingly. For 938 instance, in an event-centric system, ringing a door bell would 939 result in a message being sent that represents the event that it was 940 rung. 942 In resource-oriented paradigms such as REST, messages usually carry 943 the current state of the remote resource, independent from the 944 changes (i.e., events) that have lead to that state. In a naive yet 945 natural design, a door bell could be modeled as a resource that can 946 have the states unpressed and pressed. There are, however, a few 947 issues with this approach. Polling is not an option, as it is highly 948 unlikely to be able to observe the pressed state with any realistic 949 polling interval. When using CoAP Observe with Confirmable 950 notifications, the server will usually send two notifications for the 951 event that the door bell was pressed: notification for changing from 952 unpressed to pressed and another one for changing back to unpressed. 953 If the time between the state changes is very short, the server might 954 drop the first notification, as Observe only guarantees only eventual 955 consistency (see Section 1.3 of [RFC7641]). 957 The solution is to pick a state model that fits better to the 958 application. In the case of the door bell - and many other event- 959 driven resources - the solution could be a counter that counts how 960 often the bell was pressed. The corresponding action is taken each 961 time the client observes a change in the received representation. 963 In the case of a network outage, this could lead to a ringing sound 964 10 minutes after the bell was rung. Also including a timestamp of 965 the last counter increment in the state can help to suppress ringing 966 a sound when the event has become obsolete. 968 6.3. Server Push 970 Overall, a universal mechanism for server push, that is, change-of- 971 state notifications and stand-alone event notifications, is still an 972 open issue that is being discussed in the Thing-to-Thing Research 973 Group. It is connected to the state-event duality problem and 974 custody transfer, that is, the transfer of the responsibility that a 975 message (e.g., event) is delivered successfully. 977 A proficient mechanism for change-of-state notifications is currently 978 only available for CoAP: Observing resources [RFC7641]. It offers 979 enventual consistency, which guarantees "that if the resource does 980 not undergo a new change in state, eventually all registered 981 observers will have a current representation of the latest resource 982 state". It intrinsically deals with the challenges of lossy 983 networks, where notifications might be lost, and constrained 984 networks, where there might not be enough bandwidth to propagate all 985 changes. 987 For stand-alone event notifications, that is, where every single 988 notification contains an identifiable event that must not be lost, 989 observing resources is not a good fit. A better strategy is to model 990 each event as a new resource, whose existence is notified through 991 change-of-state notifications of an index resource (cf. Collection 992 pattern). Large numbers of events will cause the notification to 993 grow large, as it needs to contain a large number of Web links. 994 Blockwise transfers [RFC7959] can help here. When the links are 995 ordered by freshness of the events, the first block can already 996 contain all links to new events. Then, observers do not need to 997 retrieve the remaining blocks from the server, but only the 998 representations of the new event resources. 1000 An alternative pattern is to exploit the dual roles of IoT devices, 1001 in particular when using CoAP: they are usually client and server at 1002 the same time. A client observer would subscribe to events by 1003 registering a callback URI at the origin server, e.g., using a POST 1004 request and receiving the location of a temporary subscription 1005 resource as handle. The origin server would then publish events by 1006 sending POST requests containing the event to the observer. The 1007 cancellation can be modeled through deleting the subscription 1008 resource. This pattern makes the origin server responsible for 1009 delivering the event notifications. This goes beyond retransmissions 1010 of messages; the origin server is usually supposed to queue all 1011 undelivered events and to retry until successful delivery or explicit 1012 cancellation. In HTTP, this pattern is known as REST Hooks. 1014 In HTTP, there exist a number of workarounds to enable server push, 1015 e.g., long polling and streaming [RFC6202] or server-sent events 1016 [W3C.REC-html5-20141028]. Long polling as an extension that both 1017 server and client need to be aware of. In IoT systems, long polling 1018 can introduce a considerable overhead, as the request has to be 1019 repeated for each notification. Streaming and server-sent events (in 1020 fact an evolved version of streaming) are more efficient, as only one 1021 request is sent. However, there is only one response header and 1022 subsequent notifications can only have content. There are no means 1023 for individual status and metadata, and hence no means for proficient 1024 error handling (e.g., when the resource is deleted). 1026 7. Security Considerations 1028 This document does not define new functionality and therefore does 1029 not introduce new security concerns. We assume that system designers 1030 apply classic Web security on top of the basic RESTful guidance given 1031 in this document. Thus, security protocols and considerations from 1032 related specifications apply to RESTful IoT design. These include: 1034 o Transport Layer Security (TLS): [RFC5246] and [RFC6347] 1036 o Internet X.509 Public Key Infrastructure: [RFC5280] 1037 o HTTP security: Section 9 of [RFC7230], Section 9 of [RFC7231], 1038 etc. 1040 o CoAP security: Section 11 of [RFC7252] 1042 o URI security: Section 7 of [RFC3986] 1044 IoT-specific security is mainly work in progress at the time of 1045 writing. First specifications include: 1047 o (D)TLS Profiles for the Internet of Things: [RFC7925] 1049 Further IoT security considerations are available in 1050 [I-D.irtf-t2trg-iot-seccons]. 1052 8. Acknowledgement 1054 The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero 1055 Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, Dave 1056 Thaler, Erik Wilde, and Niklas Widell for the reviews and feedback. 1058 9. References 1060 9.1. Normative References 1062 [I-D.ietf-core-object-security] 1063 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1064 "Object Security for Constrained RESTful Environments 1065 (OSCORE)", draft-ietf-core-object-security-12 (work in 1066 progress), March 2018. 1068 [I-D.ietf-core-resource-directory] 1069 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1070 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1071 resource-directory-13 (work in progress), March 2018. 1073 [REST] Fielding, R., "Architectural Styles and the Design of 1074 Network-based Software Architectures", Ph.D. Dissertation, 1075 University of California, Irvine , 2000. 1077 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1078 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1079 3986, DOI 10.17487/RFC3986, January 2005, 1080 . 1082 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1083 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1084 RFC5246, August 2008, . 1087 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1088 Housley, R., and W. Polk, "Internet X.509 Public Key 1089 Infrastructure Certificate and Certificate Revocation List 1090 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1091 . 1093 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 1094 for the Simple Network Management Protocol (SNMP)", STD 1095 78, RFC 5590, DOI 10.17487/RFC5590, June 2009, 1096 . 1098 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ 1099 RFC5988, October 2010, . 1102 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1103 "Known Issues and Best Practices for the Use of Long 1104 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1105 DOI 10.17487/RFC6202, April 2011, . 1108 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1109 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1110 January 2012, . 1112 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1113 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1114 . 1116 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1117 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1118 October 2013, . 1120 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1121 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 1122 7230, DOI 10.17487/RFC7230, June 2014, . 1125 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1126 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 1127 10.17487/RFC7231, June 2014, . 1130 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1131 Application Protocol (CoAP)", RFC 7641, DOI 10.17487/ 1132 RFC7641, September 2015, . 1135 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1136 the Constrained Application Protocol (CoAP)", RFC 7959, 1137 DOI 10.17487/RFC7959, August 2016, . 1140 [W3C.REC-exi-20110310] 1141 Schneider, J. and T. Kamiya, "Efficient XML Interchange 1142 (EXI) Format 1.0", World Wide Web Consortium 1143 Recommendation REC-exi-20110310, March 2011, 1144 . 1146 [W3C.REC-html5-20141028] 1147 Hickson, I., Berjon, R., Faulkner, S., Leithead, T., 1148 Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", 1149 World Wide Web Consortium Recommendation REC- 1150 html5-20141028, October 2014, 1151 . 1153 9.2. Informative References 1155 [CollectionJSON] 1156 Amundsen, M., "Collection+JSON - Document Format", 1157 February 2013, 1158 . 1160 [I-D.ietf-core-coap-pubsub] 1161 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1162 Subscribe Broker for the Constrained Application Protocol 1163 (CoAP)", draft-ietf-core-coap-pubsub-04 (work in 1164 progress), March 2018. 1166 [I-D.ietf-core-senml] 1167 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1168 Bormann, "Media Types for Sensor Measurement Lists 1169 (SenML)", draft-ietf-core-senml-14 (work in progress), 1170 April 2018. 1172 [I-D.irtf-t2trg-iot-seccons] 1173 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 1174 the-Art and Challenges for the Internet of Things 1175 Security", draft-irtf-t2trg-iot-seccons-14 (work in 1176 progress), April 2018. 1178 [IANA-CoAP-media] 1179 "CoAP Content-Formats", n.d., 1180 . 1183 [IANA-media-types] 1184 "Media Types", n.d., . 1187 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1188 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1189 . 1191 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 1192 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 1193 2013, . 1195 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1196 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1197 2014, . 1199 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1200 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 1201 RFC7228, May 2014, . 1204 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1205 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 1206 RFC7252, June 2014, . 1209 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 1210 7320, DOI 10.17487/RFC7320, July 2014, . 1213 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1214 Security (TLS) / Datagram Transport Layer Security (DTLS) 1215 Profiles for the Internet of Things", RFC 7925, DOI 1216 10.17487/RFC7925, July 2016, . 1219 Appendix A. Future Work 1221 o Interface semantics: shared knowledge among system components (URI 1222 schemes, media types, relation types, well-known locations; see 1223 core-apps) 1225 o Unreliable (best effort) communication, robust communication in 1226 network with high packet loss, 3-way commit 1228 o Discuss directories, such as CoAP Resource Directory 1230 o More information on how to design resources; choosing what is 1231 modeled as a resource, etc. 1233 Authors' Addresses 1235 Ari Keranen 1236 Ericsson 1237 Jorvas 02420 1238 Finland 1240 Email: ari.keranen@ericsson.com 1242 Matthias Kovatsch 1243 ETH Zurich 1244 Universitaetstrasse 6 1245 Zurich CH-8092 1246 Switzerland 1248 Email: kovatsch@inf.ethz.ch 1250 Klaus Hartke 1251 Universitaet Bremen TZI 1252 Postfach 330440 1253 Bremen D-28359 1254 Germany 1256 Email: hartke@tzi.org