< draft-irtf-t2trg-rest-iot-03.txt   draft-irtf-t2trg-rest-iot-04.txt >
Network Working Group A. Keranen Network Working Group A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational M. Kovatsch Intended status: Informational M. Kovatsch
Expires: October 21, 2019 Siemens AG Expires: January 9, 2020 Siemens AG
K. Hartke K. Hartke
Ericsson Ericsson
April 19, 2019 July 08, 2019
RESTful Design for Internet of Things Systems RESTful Design for Internet of Things Systems
draft-irtf-t2trg-rest-iot-03 draft-irtf-t2trg-rest-iot-04
Abstract Abstract
This document gives guidance for designing Internet of Things (IoT) This document gives guidance for designing Internet of Things (IoT)
systems that follow the principles of the Representational State systems that follow the principles of the Representational State
Transfer (REST) architectural style. This document is a product of Transfer (REST) architectural style. This document is a product of
the IRTF Thing-to-Thing Research Group (T2TRG). the IRTF Thing-to-Thing Research Group (T2TRG).
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 7
3.2. System design . . . . . . . . . . . . . . . . . . . . . . 8 3.2. System design . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Uniform Resource Identifiers (URIs) . . . . . . . . . . . 9 3.3. Uniform Resource Identifiers (URIs) . . . . . . . . . . . 10
3.4. Representations . . . . . . . . . . . . . . . . . . . . . 11 3.4. Representations . . . . . . . . . . . . . . . . . . . . . 11
3.5. HTTP/CoAP Methods . . . . . . . . . . . . . . . . . . . . 11 3.5. HTTP/CoAP Methods . . . . . . . . . . . . . . . . . . . . 12
3.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.5. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.5. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.6. PATCH . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.6. PATCH . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. HTTP/CoAP Status/Response Codes . . . . . . . . . . . . . 14 3.6. HTTP/CoAP Status/Response Codes . . . . . . . . . . . . . 14
4. REST Constraints . . . . . . . . . . . . . . . . . . . . . . 14 4. REST Constraints . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Client-Server . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Client-Server . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Stateless . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Stateless . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Uniform Interface . . . . . . . . . . . . . . . . . . . . 16 4.4. Uniform Interface . . . . . . . . . . . . . . . . . . . . 17
4.5. Layered System . . . . . . . . . . . . . . . . . . . . . 17 4.5. Layered System . . . . . . . . . . . . . . . . . . . . . 18
4.6. Code-on-Demand . . . . . . . . . . . . . . . . . . . . . 18 4.6. Code-on-Demand . . . . . . . . . . . . . . . . . . . . . 18
5. Hypermedia-driven Applications . . . . . . . . . . . . . . . 18 5. Hypermedia-driven Applications . . . . . . . . . . . . . . . 19
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Interaction . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Interaction . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Hypermedia-driven Design Guidance . . . . . . . . . . . . 20 5.4. Hypermedia-driven Design Guidance . . . . . . . . . . . . 21
6. Design Patterns . . . . . . . . . . . . . . . . . . . . . . . 20 6. Design Patterns . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Calling a Procedure . . . . . . . . . . . . . . . . . . . 21 6.2. Calling a Procedure . . . . . . . . . . . . . . . . . . . 22
6.2.1. Instantly Returning Procedures . . . . . . . . . . . 21 6.2.1. Instantly Returning Procedures . . . . . . . . . . . 22
6.2.2. Long-running Procedures . . . . . . . . . . . . . . . 22 6.2.2. Long-running Procedures . . . . . . . . . . . . . . . 22
6.2.3. Conversion . . . . . . . . . . . . . . . . . . . . . 22 6.2.3. Conversion . . . . . . . . . . . . . . . . . . . . . 23
6.2.4. Events as State . . . . . . . . . . . . . . . . . . . 23 6.2.4. Events as State . . . . . . . . . . . . . . . . . . . 23
6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Representational State Transfer (REST) architectural style [REST] The Representational State Transfer (REST) architectural style [REST]
is a set of guidelines and best practices for building distributed is a set of guidelines and best practices for building distributed
hypermedia systems. At its core is a set of constraints, which when hypermedia systems. At its core is a set of constraints, which when
fulfilled enable desirable properties for distributed software fulfilled enable desirable properties for distributed software
systems such as scalability and modifiability. When REST principles systems such as scalability and modifiability. When REST principles
are applied to the design of a system, the result is often called are applied to the design of a system, the result is often called
RESTful and in particular an API following these principles is called RESTful and in particular an API following these principles is called
skipping to change at page 3, line 25 skipping to change at page 3, line 25
Different protocols can be used with RESTful systems, but at the time Different protocols can be used with RESTful systems, but at the time
of writing the most common protocols are HTTP [RFC7230] and CoAP of writing the most common protocols are HTTP [RFC7230] and CoAP
[RFC7252]. Since RESTful APIs are often simple and lightweight, they [RFC7252]. Since RESTful APIs are often simple and lightweight, they
are a good fit for various IoT applications. The goal of this are a good fit for various IoT applications. The goal of this
document is to give basic guidance for designing RESTful systems and document is to give basic guidance for designing RESTful systems and
APIs for IoT applications and give pointers for more information. APIs for IoT applications and give pointers for more information.
Design of a good RESTful IoT system has naturally many commonalities Design of a good RESTful IoT system has naturally many commonalities
with other Web systems. Compared to other systems, the key with other Web systems. Compared to other systems, the key
characteristics of many IoT systems include: characteristics of many RESTful IoT systems include:
o need to accommodate for constrained devices, so with IoT, REST is o need to accommodate for constrained devices, so with IoT, REST is
not only used for scaling out (large number of clients on a web not only used for scaling out (large number of clients on a web
server), but also for scaling down (efficient server on server), but also for scaling down (efficient server on
constrained node) constrained node)
o data formats, interaction patterns, and other mechanisms that o data formats, interaction patterns, and other mechanisms that
minimize, or preferably avoid, the need for human interaction minimize, or preferably avoid, the need for human interaction
o for some classes [RFC7228] of server endpoints, significant
constraints, e.g., in energy consumption, and thus implementation
complexity, may apply
o endpoints are commonly both clients and servers
o preference for compact and simple data formats to facilitate o preference for compact and simple data formats to facilitate
efficient transfer over (often) constrained networks and efficient transfer over (often) constrained networks and
lightweight processing in constrained nodes lightweight processing in constrained nodes
o the usually large number of endpoints can not be updated o the usually large number of endpoints can not be updated
simultaneously, yet the system needs to be able to evolve in the simultaneously, yet the system needs to be able to evolve in the
field without long downtimes field without long downtimes
2. Terminology 2. Terminology
skipping to change at page 4, line 45 skipping to change at page 5, line 7
Forward Proxy: An intermediary that is selected by a client, usually Forward Proxy: An intermediary that is selected by a client, usually
via local configuration rules, and that can be tasked to make via local configuration rules, and that can be tasked to make
requests on behalf of the client. This may be useful, for requests on behalf of the client. This may be useful, for
example, when the client lacks the capability to make the request example, when the client lacks the capability to make the request
itself or to service the response from a cache in order to reduce itself or to service the response from a cache in order to reduce
response time, network bandwidth, and energy consumption. response time, network bandwidth, and energy consumption.
Gateway: A reverse proxy that provides an interface to a non-RESTful Gateway: A reverse proxy that provides an interface to a non-RESTful
system such as legacy systems or alternative technologies such as system such as legacy systems or alternative technologies such as
Bluetooth ATT/GATT. See also "Reverse Proxy". Bluetooth Attribute Profile (ATT) or Generic Attribute Profile
(GATT). See also "Reverse Proxy".
Hypermedia Control: A component, such as a link or a form, embedded Hypermedia Control: A component, such as a link or a form, embedded
in a representation that identifies a resource for future in a representation that identifies a resource for future
hypermedia interactions. If the client engages in an interaction hypermedia interactions. If the client engages in an interaction
with the identified resource, the result may be a change to with the identified resource, the result may be a change to
resource state and/or client state. resource state and/or client state.
Idempotent Method: A method where multiple identical requests with Idempotent Method: A method where multiple identical requests with
that method lead to the same visible resource state as a single that method lead to the same visible resource state as a single
such request. such request.
skipping to change at page 7, line 37 skipping to change at page 7, line 48
| User (C)-------------------(S) Origin | | User (C)-------------------(S) Origin |
| Agent | | Server | | Agent | | Server |
|________| |_________| |________| |_________|
(Browser) (Web Server) (Browser) (Web Server)
Figure 1: Client-Server Communication Figure 1: Client-Server Communication
Intermediaries (such as forward proxies, reverse proxies, and Intermediaries (such as forward proxies, reverse proxies, and
gateways) implement both roles, but only forward requests to other gateways) implement both roles, but only forward requests to other
intermediaries or origin servers. They can also translate requests intermediaries or origin servers. They can also translate requests
to different protocols, for instance, as CoAP-HTTP cross-proxies. to different protocols, for instance, as CoAP-HTTP cross-proxies
[RFC8075].
________ __________ _________ ________ __________ _________
| | | | | | | | | | | |
| User (C)---(S) Inter- (C)--------------------(S) Origin | | User (C)---(S) Inter- (C)--------------------(S) Origin |
| Agent | | mediary | | Server | | Agent | | mediary | | Server |
|________| |__________| |_________| |________| |__________| |_________|
(Browser) (Forward Proxy) (Web Server) (Browser) (Forward Proxy) (Web Server)
Figure 2: Communication with Forward Proxy Figure 2: Communication with Forward Proxy
skipping to change at page 10, line 15 skipping to change at page 10, line 34
significant to least significant). A scheme creates a namespace for significant to least significant). A scheme creates a namespace for
resources and defines how the following components identify a resources and defines how the following components identify a
resource within that namespace. The authority identifies an entity resource within that namespace. The authority identifies an entity
that governs part of the namespace, such as the server that governs part of the namespace, such as the server
"www.example.org" in the "http" scheme. A host name (e.g., a fully "www.example.org" in the "http" scheme. A host name (e.g., a fully
qualified domain name) or an IP address, potentially followed by a qualified domain name) or an IP address, potentially followed by a
transport layer port number, are usually used in the authority transport layer port number, are usually used in the authority
component for the "http" and "coap" schemes. The path and query component for the "http" and "coap" schemes. The path and query
contain data to identify a resource within the scope of the URI's contain data to identify a resource within the scope of the URI's
scheme and naming authority. The fragment allows to refer to some scheme and naming authority. The fragment allows to refer to some
portion of the resource, such as a Record in a SenML Pack. However, portion of the resource, such as a Record in a SenML Pack (Section 9
fragments are processed only at client side and not sent on the wire. of [RFC8428]). However, fragments are processed only at client side
[RFC7320] provides more details on URI design and ownership with best and not sent on the wire. [RFC7320] provides more details on URI
current practices for establishing URI structures, conventions, and design and ownership with best current practices for establishing URI
formats. structures, conventions, and formats.
For RESTful IoT applications, typical schemes include "https", For RESTful IoT applications, typical schemes include "https",
"coaps", "http", and "coap". These refer to HTTP and CoAP, with and "coaps", "http", and "coap". These refer to HTTP and CoAP, with and
without Transport Layer Security (TLS) [RFC5246]. (CoAP uses without Transport Layer Security (TLS) [RFC5246]. (CoAP uses
Datagram TLS (DTLS) [RFC6347], the variant of TLS for UDP.) These Datagram TLS (DTLS) [RFC6347], the variant of TLS for UDP.) These
four schemes also provide means for locating the resource; using the four schemes also provide means for locating the resource; using the
HTTP protocol for "http" and "https", and with the CoAP protocol for HTTP protocol for "http" and "https", and with the CoAP protocol for
"coap" and "coaps". If the scheme is different for two URIs (e.g., "coap" and "coaps". If the scheme is different for two URIs (e.g.,
"coap" vs. "coaps"), it is important to note that even if the rest of "coap" vs. "coaps"), it is important to note that even if the rest of
the URI is identical, these are two different resources, in two the URI is identical, these are two different resources, in two
skipping to change at page 11, line 9 skipping to change at page 11, line 22
such established semantics and are not commonly used. Whether the such established semantics and are not commonly used. Whether the
order of the query parameters matters in URIs is unspecified and they order of the query parameters matters in URIs is unspecified and they
can be re-ordered e.g., by proxies. Therefore applications should can be re-ordered e.g., by proxies. Therefore applications should
not rely on their order; see Section 3.3 of [RFC6943] for more not rely on their order; see Section 3.3 of [RFC6943] for more
details. details.
3.4. Representations 3.4. Representations
Clients can retrieve the resource state from an origin server or Clients can retrieve the resource state from an origin server or
manipulate resource state on the origin server by transferring manipulate resource state on the origin server by transferring
resource representations. Resource representations have a media type resource representations. Resource representations have a content-
that tells how the representation should be interpreted by type (media-type, optionally with parameters) that tells how the
identifying the representation format used. representation should be interpreted by identifying the
representation format used.
Typical media types for IoT systems include: Typical media-types for IoT systems include:
o "text/plain" for simple UTF-8 text o "text/plain" for simple UTF-8 text
o "application/octet-stream" for arbitrary binary data o "application/octet-stream" for arbitrary binary data
o "application/json" for the JSON format [RFC7159] o "application/json" for the JSON format [RFC7159]
o "application/cbor" for CBOR [RFC7049] o "application/cbor" for CBOR [RFC7049]
o "application/exi" for EXI [W3C.REC-exi-20110310] o "application/exi" for EXI [W3C.REC-exi-20110310]
o "application/link-format" for CoRE Link Format [RFC6690]
o "application/senml+json" and "application/senml+cbor" for Sensor o "application/senml+json" and "application/senml+cbor" for Sensor
Measurement Lists (SenML) data [RFC8428] Measurement Lists (SenML) data [RFC8428]
A full list of registered Internet Media Types is available at the A full list of registered Internet Media Types is available at the
IANA registry [IANA-media-types] and numerical media types registered IANA registry [IANA-media-types] and numerical identifiers for media-
for use with CoAP are listed at CoAP Content-Formats IANA registry types, parameters, and content-codings registered for use with CoAP
[IANA-CoAP-media]. are listed at CoAP Content-Formats IANA registry [IANA-CoAP-media].
The terms "media-type", "content-type", and "content-format" (short
identifier of content-type and content-coding, abbreviated for
historical reasons "ct") are often used when referring to
representation formats used with CoAP. The differences between these
terms are discussed in more detail in
[I-D.bormann-core-media-content-type-format].
3.5. HTTP/CoAP Methods 3.5. HTTP/CoAP Methods
Section 4.3 of [RFC7231] defines the set of methods in HTTP; Section 4.3 of [RFC7231] defines the set of methods in HTTP;
Section 5.8 of [RFC7252] defines the set of methods in CoAP. As part Section 5.8 of [RFC7252] defines the set of methods in CoAP. As part
of the Uniform Interface constraint, each method can have certain of the Uniform Interface constraint, each method can have certain
properties that give guarantees to clients. properties that give guarantees to clients.
Safe methods do not cause any state change on the origin server when Safe methods do not cause any state change on the origin server when
applied to a resource. For example, the GET method only returns a applied to a resource. For example, the GET method only returns a
skipping to change at page 16, line 15 skipping to change at page 16, line 41
to be discarded. to be discarded.
Cache improves performance, as less data needs to be transferred and Cache improves performance, as less data needs to be transferred and
response times can be reduced significantly. Less transfers also response times can be reduced significantly. Less transfers also
improves scalability, as origin servers can be protected from too improves scalability, as origin servers can be protected from too
many requests. Local caches furthermore improve reliability, since many requests. Local caches furthermore improve reliability, since
requests can be answered even if the origin server is temporarily not requests can be answered even if the origin server is temporarily not
available. available.
Caching usually only makes sense when the data is used by multiple Caching usually only makes sense when the data is used by multiple
participants. In the IoT, however, it might make sense to cache also participants. In IoT systems, however, it might make sense to cache
individual data to protect constrained devices from frequent requests also individual data to protect constrained devices and networks from
of data that does not change often. Security often hinders the frequent requests of data that does not change often. Security often
ability to cache responses. For IoT systems, object security may be hinders the ability to cache responses. For IoT systems, object
preferable over transport layer security, as it enables security [I-D.ietf-core-object-security] may be preferable over
intermediaries to cache responses while preserving security. transport layer security, as it enables intermediaries to cache
responses while preserving security.
4.4. Uniform Interface 4.4. Uniform Interface
All RESTful APIs use the same, uniform interface independent of the All RESTful APIs use the same, uniform interface independent of the
application. This simple interaction model is enabled by exchanging application. This simple interaction model is enabled by exchanging
representations and modifying state locally, which simplifies the representations and modifying state locally, which simplifies the
interface between clients and servers to a small set of methods to interface between clients and servers to a small set of methods to
retrieve, update, and delete state - which applies to all retrieve, update, and delete state - which applies to all
applications. applications.
skipping to change at page 17, line 5 skipping to change at page 17, line 36
o representation formats to represent and manipulate resource state o representation formats to represent and manipulate resource state
o self-descriptive messages with a standard set of methods (e.g., o self-descriptive messages with a standard set of methods (e.g.,
GET, POST, PUT, DELETE with their guaranteed properties) GET, POST, PUT, DELETE with their guaranteed properties)
o hypermedia controls within representations o hypermedia controls within representations
The concept of hypermedia controls is also known as HATEOAS: The concept of hypermedia controls is also known as HATEOAS:
Hypermedia As The Engine Of Application State. The origin server Hypermedia As The Engine Of Application State. The origin server
embeds controls for the interface into its representations and embeds controls for the interface into its representations and
thereby informs the client about possible next requests. The mostly thereby informs the client about possible next requests. The most
used control for RESTful systems is Web Linking [RFC5590]. used control for RESTful systems today is Web Linking [RFC5988].
Hypermedia forms are more powerful controls that describe how to Hypermedia forms are more powerful controls that describe how to
construct more complex requests, including representations to modify construct more complex requests, including representations to modify
resource state. resource state.
While this is the most complex constraints (in particular the While this is the most complex constraints (in particular the
hypermedia controls), it improves many different key properties. It hypermedia controls), it improves many different key properties. It
improves simplicity, as uniform interfaces are easier to understand. improves simplicity, as uniform interfaces are easier to understand.
The self-descriptive messages improve visibility. The limitation to The self-descriptive messages improve visibility. The limitation to
a known set of representation formats fosters portability. Most of a known set of representation formats fosters portability. Most of
all, however, this constraint is the key to modifiability, as all, however, this constraint is the key to modifiability, as
skipping to change at page 19, line 35 skipping to change at page 20, line 18
interaction with a server. This includes what resources are interaction with a server. This includes what resources are
available, what representations of resource states are available, available, what representations of resource states are available,
what each representation describes, how to retrieve a representation, what each representation describes, how to retrieve a representation,
what state changing operations on a resource are possible, how to what state changing operations on a resource are possible, how to
perform these operations, and so on. perform these operations, and so on.
Some part of this knowledge, such as how to retrieve the Some part of this knowledge, such as how to retrieve the
representation of a resource state, is typically hard-coded in the representation of a resource state, is typically hard-coded in the
client software. For other parts, a choice can often be made between client software. For other parts, a choice can often be made between
hard-coding the knowledge or acquiring it on-demand. The key to hard-coding the knowledge or acquiring it on-demand. The key to
success in either case is the use in-band information for identifying success in either case is the use of in-band information for
the knowledge that is required. This enables the client to verify identifying the knowledge that is required. This enables the client
that is has all required knowledge and to acquire missing knowledge to verify that it has all the required knowledge or to acquire
on-demand. missing knowledge on-demand.
A hypermedia-driven application typically uses the following A hypermedia-driven application typically uses the following
identifiers: identifiers:
o URI schemes that identify communication protocols, o URI schemes that identify communication protocols,
o Internet Media Types that identify representation formats, o Internet Media Types that identify representation formats,
o link relation types or resource types that identify link o link relation types or resource types that identify link
semantics, semantics,
skipping to change at page 23, line 20 skipping to change at page 23, line 48
aware of each occurrence of the event and can react accordingly. For aware of each occurrence of the event and can react accordingly. For
instance, in an event-centric system, ringing a door bell would instance, in an event-centric system, ringing a door bell would
result in a message being sent that represents the event that it was result in a message being sent that represents the event that it was
rung. rung.
In resource-oriented paradigms such as REST, messages usually carry In resource-oriented paradigms such as REST, messages usually carry
the current state of the remote resource, independent from the the current state of the remote resource, independent from the
changes (i.e., events) that have lead to that state. In a naive yet changes (i.e., events) that have lead to that state. In a naive yet
natural design, a door bell could be modeled as a resource that can natural design, a door bell could be modeled as a resource that can
have the states unpressed and pressed. There are, however, a few have the states unpressed and pressed. There are, however, a few
issues with this approach. Polling is not an option, as it is highly issues with this approach. Polling (i.e., periodically retrieving)
unlikely to be able to observe the pressed state with any realistic the door bell resource state is not a good option, as the client is
polling interval. When using CoAP Observe with Confirmable highly unlikely to be able to observe all the changes in the pressed
notifications, the server will usually send two notifications for the state with any realistic polling interval. When using CoAP Observe
event that the door bell was pressed: notification for changing from with Confirmable notifications, the server will usually send two
unpressed to pressed and another one for changing back to unpressed. notifications for the event that the door bell was pressed:
If the time between the state changes is very short, the server might notification for changing from unpressed to pressed and another one
drop the first notification, as Observe only guarantees only eventual for changing back to unpressed. If the time between the state
consistency (see Section 1.3 of [RFC7641]). changes is very short, the server might drop the first notification,
as Observe only guarantees only eventual consistency (see Section 1.3
of [RFC7641]).
The solution is to pick a state model that fits better to the The solution is to pick a state model that fits better to the
application. In the case of the door bell - and many other event- application. In the case of the door bell - and many other event-
driven resources - the solution could be a counter that counts how driven resources - the solution could be a counter that counts how
often the bell was pressed. The corresponding action is taken each often the bell was pressed. The corresponding action is taken each
time the client observes a change in the received representation. time the client observes a change in the received representation. In
the case of a network outage, this could lead to a ringing sound long
In the case of a network outage, this could lead to a ringing sound after the bell was rung. Also including a timestamp of the last
10 minutes after the bell was rung. Also including a timestamp of counter increment in the state can help to suppress ringing a sound
the last counter increment in the state can help to suppress ringing when the event has become obsolete. Another solution would be to
a sound when the event has become obsolete. change the client/server roles of the door bell button and the
ringer, as described in Section 6.3.
6.3. Server Push 6.3. Server Push
Overall, a universal mechanism for server push, that is, change-of- Overall, a universal mechanism for server push, that is, change-of-
state notifications and stand-alone event notifications, is still an state notifications and stand-alone event notifications, is still an
open issue that is being discussed in the Thing-to-Thing Research open issue that is being discussed in the Thing-to-Thing Research
Group. It is connected to the state-event duality problem and Group. It is connected to the state-event duality problem and
custody transfer, that is, the transfer of the responsibility that a custody transfer, that is, the transfer of the responsibility that a
message (e.g., event) is delivered successfully. message (e.g., event) is delivered successfully.
A proficient mechanism for change-of-state notifications is currently A proficient mechanism for change-of-state notifications is currently
only available for CoAP: Observing resources [RFC7641]. It offers only available for CoAP: Observing resources [RFC7641]. The CoAP
enventual consistency, which guarantees "that if the resource does Observe mechanism offers eventual consistency, which guarantees "that
not undergo a new change in state, eventually all registered if the resource does not undergo a new change in state, eventually
observers will have a current representation of the latest resource all registered observers will have a current representation of the
state". It intrinsically deals with the challenges of lossy latest resource state". It intrinsically deals with the challenges
networks, where notifications might be lost, and constrained of lossy networks, where notifications might be lost, and constrained
networks, where there might not be enough bandwidth to propagate all networks, where there might not be enough bandwidth to propagate all
changes. changes.
For stand-alone event notifications, that is, where every single For stand-alone event notifications, that is, where every single
notification contains an identifiable event that must not be lost, notification contains an identifiable event that must not be lost,
observing resources is not a good fit. A better strategy is to model observing resources is not a good fit. A better strategy is to model
each event as a new resource, whose existence is notified through each event as a new resource, whose existence is notified through
change-of-state notifications of an index resource (cf. Collection change-of-state notifications of an index resource (cf. Collection
pattern). Large numbers of events will cause the notification to pattern). Large numbers of events will cause the notification to
grow large, as it needs to contain a large number of Web links. grow large, as it needs to contain a large number of Web links.
Blockwise transfers [RFC7959] can help here. When the links are Block-wise transfers [RFC7959] can help here. When the links are
ordered by freshness of the events, the first block can already ordered by freshness of the events, the first block can already
contain all links to new events. Then, observers do not need to contain all links to new events. Then, observers do not need to
retrieve the remaining blocks from the server, but only the retrieve the remaining blocks from the server, but only the
representations of the new event resources. representations of the new event resources.
An alternative pattern is to exploit the dual roles of IoT devices, An alternative pattern is to exploit the dual roles of IoT devices,
in particular when using CoAP: they are usually client and server at in particular when using CoAP: they are usually client and server at
the same time. A client observer would subscribe to events by the same time. An endpoint interested in observing the events would
registering a callback URI at the origin server, e.g., using a POST subscribe to them by registering a callback URI at the origin server,
request and receiving the location of a temporary subscription e.g., using a POST request with the URI or a hypermedia document in
resource as handle. The origin server would then publish events by the payload, and receiving the location of a temporary "subscription
sending POST requests containing the event to the observer. The resource" as handle in the response. The origin server would then
cancellation can be modeled through deleting the subscription publish events by sending requests containing the event data to the
resource. This pattern makes the origin server responsible for observer's callback URI; here POST can be used to add events to a
delivering the event notifications. This goes beyond retransmissions collection located at the callback URI or PUT can be used when the
of messages; the origin server is usually supposed to queue all event data is a new state that shall replace the outdated state at
undelivered events and to retry until successful delivery or explicit the callback URI. The cancellation can be modeled through deleting
cancellation. In HTTP, this pattern is known as REST Hooks. the subscription resource. This pattern makes the origin server
responsible for delivering the event notifications. This goes beyond
retransmissions of messages; the origin server is usually supposed to
queue all undelivered events and to retry until successful delivery
or explicit cancellation. In HTTP, this pattern is known as REST
Hooks.
In HTTP, there exist a number of workarounds to enable server push, In HTTP, there exist a number of workarounds to enable server push,
e.g., long polling and streaming [RFC6202] or server-sent events e.g., long polling and streaming [RFC6202] or server-sent events
[W3C.REC-html5-20141028]. Long polling as an extension that both [W3C.REC-html5-20141028]. In IoT systems, long polling can introduce
server and client need to be aware of. In IoT systems, long polling a considerable overhead, as the request has to be repeated for each
can introduce a considerable overhead, as the request has to be notification. Streaming and server-sent events (the latter is
repeated for each notification. Streaming and server-sent events (in actually an evolution of the former) are more efficient, as only one
fact an evolved version of streaming) are more efficient, as only one
request is sent. However, there is only one response header and request is sent. However, there is only one response header and
subsequent notifications can only have content. There are no means subsequent notifications can only have content. Individual status
for individual status and metadata, and hence no means for proficient and metadata needs to be included in the content message. This
error handling (e.g., when the resource is deleted). reduces HTTP again to a pure transport, as its status signaling and
metadata capabilities cannot be used.
7. Security Considerations 7. Security Considerations
This document does not define new functionality and therefore does This document does not define new functionality and therefore does
not introduce new security concerns. We assume that system designers not introduce new security concerns. We assume that system designers
apply classic Web security on top of the basic RESTful guidance given apply classic Web security on top of the basic RESTful guidance given
in this document. Thus, security protocols and considerations from in this document. Thus, security protocols and considerations from
related specifications apply to RESTful IoT design. These include: related specifications apply to RESTful IoT design. These include:
o Transport Layer Security (TLS): [RFC5246] and [RFC6347] o Transport Layer Security (TLS): [RFC5246] and [RFC6347]
skipping to change at page 25, line 16 skipping to change at page 26, line 4
This document does not define new functionality and therefore does This document does not define new functionality and therefore does
not introduce new security concerns. We assume that system designers not introduce new security concerns. We assume that system designers
apply classic Web security on top of the basic RESTful guidance given apply classic Web security on top of the basic RESTful guidance given
in this document. Thus, security protocols and considerations from in this document. Thus, security protocols and considerations from
related specifications apply to RESTful IoT design. These include: related specifications apply to RESTful IoT design. These include:
o Transport Layer Security (TLS): [RFC5246] and [RFC6347] o Transport Layer Security (TLS): [RFC5246] and [RFC6347]
o Internet X.509 Public Key Infrastructure: [RFC5280] o Internet X.509 Public Key Infrastructure: [RFC5280]
o HTTP security: Section 9 of [RFC7230], Section 9 of [RFC7231], o HTTP security: Section 9 of [RFC7230], Section 9 of [RFC7231],
etc. etc.
o CoAP security: Section 11 of [RFC7252] o CoAP security: Section 11 of [RFC7252]
o URI security: Section 7 of [RFC3986] o URI security: Section 7 of [RFC3986]
IoT-specific security is mainly work in progress at the time of IoT-specific security is active area of standardization at the time
writing. First specifications include: of writing. First finalized specifications include:
o (D)TLS Profiles for the Internet of Things: [RFC7925] o (D)TLS Profiles for the Internet of Things: [RFC7925]
Further IoT security considerations are available in o CBOR Object Signing and Encryption (COSE) [RFC8152]
[I-D.irtf-t2trg-iot-seccons].
o CBOR Web Token [RFC8392]
o Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
[I-D.ietf-ace-cwt-proof-of-possession]
o Object Security for Constrained RESTful Environments (OSCORE)
[I-D.ietf-core-object-security]
o Authentication and Authorization for Constrained Environments
(ACE) using the OAuth 2.0 Framework [I-D.ietf-ace-oauth-authz]
o ACE profiles for DTLS [I-D.ietf-ace-dtls-authorize] and OSCORE
[I-D.ietf-ace-oscore-profile]
Further IoT security considerations are available in [RFC8576].
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero The authors would like to thank Mike Amundsen, Heidi-Maria Back,
Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, Dave Carsten Bormann, Tero Kauppinen, Michael Koster, Mert Ocak, Robby
Thaler, Erik Wilde, and Niklas Widell for the reviews and feedback. Simpson, Ravi Subramaniam, Dave Thaler, Niklas Widell, and Erik Wilde
for the reviews and feedback.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-core-dev-urn] [I-D.ietf-core-dev-urn]
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", draft-ietf-core-dev-urn-03 Names for Device Identifiers", draft-ietf-core-dev-urn-03
(work in progress), October 2018. (work in progress), October 2018.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-20 (work in progress), March 2019. resource-directory-22 (work in progress), July 2019.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation, Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine , 2000. University of California, Irvine , 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 26, line 30 skipping to change at page 27, line 36
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 5590, DOI 10.17487/RFC5590, June 2009,
<https://www.rfc-editor.org/info/rfc5590>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>. <https://www.rfc-editor.org/info/rfc5988>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011, DOI 10.17487/RFC6202, April 2011,
<https://www.rfc-editor.org/info/rfc6202>. <https://www.rfc-editor.org/info/rfc6202>.
skipping to change at page 28, line 5 skipping to change at page 28, line 49
html5-20141028, October 2014, html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>. <http://www.w3.org/TR/2014/REC-html5-20141028>.
9.2. Informative References 9.2. Informative References
[CollectionJSON] [CollectionJSON]
Amundsen, M., "Collection+JSON - Document Format", Amundsen, M., "Collection+JSON - Document Format",
February 2013, February 2013,
<http://amundsen.com/media-types/collection/format/>. <http://amundsen.com/media-types/collection/format/>.
[I-D.bormann-core-media-content-type-format]
Bormann, C., "On Media-Types, Content-Types, and related
terminology", draft-bormann-core-media-content-type-
format-00 (work in progress), March 2019.
[I-D.handrews-json-schema-validation] [I-D.handrews-json-schema-validation]
Wright, A., Andrews, H., and G. Luff, "JSON Schema Wright, A., Andrews, H., and G. Luff, "JSON Schema
Validation: A Vocabulary for Structural Validation of Validation: A Vocabulary for Structural Validation of
JSON", draft-handrews-json-schema-validation-01 (work in JSON", draft-handrews-json-schema-validation-01 (work in
progress), March 2018. progress), March 2018.
[I-D.hartke-core-apps] [I-D.hartke-core-apps]
Hartke, K., "CoRE Applications", draft-hartke-core-apps-08 Hartke, K., "CoRE Applications", draft-hartke-core-apps-08
(work in progress), October 2018. (work in progress), October 2018.
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-06 (work in progress), February 2019.
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-08 (work in progress), April 2019.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019.
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-08 (work in progress), July 2019.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-08 (work in (CoAP)", draft-ietf-core-coap-pubsub-08 (work in
progress), March 2019. progress), March 2019.
[I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-16 (work in
progress), December 2018.
[IANA-CoAP-media] [IANA-CoAP-media]
"CoAP Content-Formats", n.d., "CoAP Content-Formats", n.d.,
<http://www.iana.org/assignments/core-parameters/ <http://www.iana.org/assignments/core-parameters/
core-parameters.xhtml#content-formats>. core-parameters.xhtml#content-formats>.
[IANA-media-types] [IANA-media-types]
"Media Types", n.d., <http://www.iana.org/assignments/ "Media Types", n.d., <http://www.iana.org/assignments/
media-types/media-types.xhtml>. media-types/media-types.xhtml>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
skipping to change at page 29, line 25 skipping to change at page 30, line 45
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014, RFC 7320, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>. <https://www.rfc-editor.org/info/rfc7320>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>. <https://www.rfc-editor.org/info/rfc8428>.
[W3C-TD] Kaebisch, S. and T. Kamiya, "Web of Things (WoT) Thing [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Description", April 2018, Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>.
[W3C-TD] Kaebisch, S., Kamiya, T., McCool, M., and V. Charpenay,
"Web of Things (WoT) Thing Description", May 2019,
<https://www.w3.org/TR/wot-thing-description/>. <https://www.w3.org/TR/wot-thing-description/>.
Appendix A. Future Work Appendix A. Future Work
o Interface semantics: shared knowledge among system components (URI
schemes, media types, relation types, well-known locations; see
core-apps)
o Unreliable (best effort) communication, robust communication in o Unreliable (best effort) communication, robust communication in
network with high packet loss, 3-way commit network with high packet loss, 3-way commit
o Discuss directories, such as CoAP Resource Directory o Discuss directories, such as CoAP Resource Directory
o More information on how to design resources; choosing what is o More information on how to design resources; choosing what is
modeled as a resource, etc. modeled as a resource, etc.
Authors' Addresses Authors' Addresses
 End of changes. 49 change blocks. 
126 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/