draft-ietf-core-coap-pubsub-02.txt   draft-ietf-core-coap-pubsub-03.txt 
Network Working Group M. Koster Network Working Group M. Koster
Internet-Draft SmartThings Internet-Draft SmartThings
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: January 5, 2018 J. Jimenez Expires: August 16, 2018 J. Jimenez
Ericsson Ericsson
July 4, 2017 February 12, 2018
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-pubsub-02 draft-ietf-core-coap-pubsub-03
Abstract Abstract
The Constrained Application Protocol (CoAP), and related extensions The Constrained Application Protocol (CoAP), and related extensions
are intended to support machine-to-machine communication in systems are intended to support machine-to-machine communication in systems
where one or more nodes are resource constrained, in particular for where one or more nodes are resource constrained, in particular for
low power wireless sensor networks. This document defines a publish- low power wireless sensor networks. This document defines a publish-
subscribe broker for CoAP that extends the capabilities of CoAP for subscribe broker for CoAP that extends the capabilities of CoAP for
supporting nodes with long breaks in connectivity and/or up-time. supporting nodes with long breaks in connectivity and/or up-time.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 5, 2018. This Internet-Draft will expire on August 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. CoAP pubsub Architecture . . . . . . . . . . . . . . . . 4 3.1. CoAP Pub/sub Architecture . . . . . . . . . . . . . . . . 4
3.2. CoAP pubsub Broker . . . . . . . . . . . . . . . . . . . 4 3.2. CoAP Pub/sub Broker . . . . . . . . . . . . . . . . . . . 4
3.3. CoAP pubsub Client . . . . . . . . . . . . . . . . . . . 5 3.3. CoAP Pub/sub Client . . . . . . . . . . . . . . . . . . . 5
3.4. CoAP pubsub Topic . . . . . . . . . . . . . . . . . . . . 5 3.4. CoAP Pub/sub Topic . . . . . . . . . . . . . . . . . . . 5
3.5. Brokerless pubsub . . . . . . . . . . . . . . . . . . . . 5 3.5. Brokerless Pub/sub . . . . . . . . . . . . . . . . . . . 5
4. CoAP pubsub REST API . . . . . . . . . . . . . . . . . . . . 6 4. CoAP Pub/sub REST API . . . . . . . . . . . . . . . . . . . . 6
4.1. DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. CoAP pubsub Operation with Resource Directory . . . . . . . . 18 5. CoAP Pub/sub Operation with Resource Directory . . . . . . . 18
6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 19 6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 19
7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 19 7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 21 9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 21
9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 21 9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 21
9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 21 9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 21
9.4. Response Code value '4.29' . . . . . . . . . . . . . . . 21 9.4. Response Code value '4.29' . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 34 skipping to change at page 3, line 34
This specification requires readers to be familiar with all the terms This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC5988] and [RFC6690]. Readers and concepts that are discussed in [RFC5988] and [RFC6690]. Readers
should also be familiar with the terms and concepts discussed in should also be familiar with the terms and concepts discussed in
[RFC7252] and [I-D.ietf-core-resource-directory]. The URI template [RFC7252] and [I-D.ietf-core-resource-directory]. The URI template
format [RFC6570] is used to describe the REST interfaces defined in format [RFC6570] is used to describe the REST interfaces defined in
this specification. this specification.
This specification makes use of the following additional terminology: This specification makes use of the following additional terminology:
Publish-Subscribe (pubsub): A messaging paradigm where messages are Publish-Subscribe (pub/sub): A messaging paradigm where messages are
published to a broker and potential receivers can subscribe to the published to a broker and potential receivers can subscribe to the
broker to receive messages. The publishers do not (need to) know broker to receive messages. The publishers do not (need to) know
where the message will be eventually sent: the publications and where the message will be eventually sent: the publications and
subscriptions are matched by a broker and publications are subscriptions are matched by a broker and publications are
delivered by the broker to subscribed receivers. delivered by the broker to subscribed receivers.
CoAP pubsub service: A group of REST resources, as defined in this CoAP pub/sub service: A group of REST resources, as defined in this
document, which together implement the required features of this document, which together implement the required features of this
specification. specification.
CoAP pubsub Broker: A server node capable of receiving messages CoAP pub/sub Broker: A server node capable of receiving messages
(publications) from and sending messages to other nodes, and able (publications) from and sending messages to other nodes, and able
to match subscriptions and publications in order to route messages to match subscriptions and publications in order to route messages
to the right destinations. The broker can also temporarily store to the right destinations. The broker can also temporarily store
publications to satisfy future subscriptions and pending publications to satisfy future subscriptions and pending
notifications. notifications.
CoAP pubsub Client: A CoAP client which is capable of publish or CoAP pub/sub Client: A CoAP client which is capable of publish or
subscribe operations as defined in this specification. subscribe operations as defined in this specification.
Topic: A unique identifier for a particular item being published Topic: A unique identifier for a particular item being published
and/or subscribed to. A broker uses the topics to match and/or subscribed to. A broker uses the topics to match
subscriptions to publications. A topic is a valid CoAP URI as subscriptions to publications. A topic is a valid CoAP URI as
defined in [RFC7252] defined in [RFC7252]
3. Architecture 3. Architecture
3.1. CoAP pubsub Architecture 3.1. CoAP Pub/sub Architecture
Figure 1 shows the architecture of a CoAP pubsub service. CoAP Figure 1 shows the architecture of a CoAP pub/sub service. CoAP pub/
pubsub Clients interact with a CoAP pubsub Broker through the CoAP sub Clients interact with a CoAP pub/sub Broker through the CoAP pub/
pubsub REST API which is hosted by the Broker. State information is sub REST API which is hosted by the Broker. State information is
updated between the Clients and the Broker. The CoAP pubsub Broker updated between the Clients and the Broker. The CoAP pub/sub Broker
performs a store-and-forward of state update representations between performs a store-and-forward of state update representations between
certain CoAP pubsub Clients. Clients Subscribe to topics upon which certain CoAP pub/sub Clients. Clients Subscribe to topics upon which
representations are Published by other Clients, which are forwarded representations are Published by other Clients, which are forwarded
by the Broker to the subscribing clients. A CoAP pubsub Broker may by the Broker to the subscribing clients. A CoAP pub/sub Broker may
be used as a REST resource proxy, retaining the last published be used as a REST resource proxy, retaining the last published
representation to supply in response to Read requests from Clients. representation to supply in response to Read requests from Clients.
Clients pubsub Broker Clients pub/sub Broker
+-------+ | +-------+ |
| CoAP | | | CoAP | |
|pubsub |---------|------+ |pub/sub|---------|------+
|Client | | | +-------+ |Client | | | +-------+
+-------+ | +----| CoAP | +-------+ | +----| CoAP |
| |pubsub | | |pub/sub|
+-------+ | +----|Broker | +-------+ | +----|Broker |
| CoAP | | | +-------+ | CoAP | | | +-------+
|pubsub |---------|------+ |pub/sub|---------|------+
|Client | | |Client | |
+-------+ | +-------+ |
Figure 1: CoAP pubsub Architecture Figure 1: CoAP pub/sub Architecture
3.2. CoAP pubsub Broker 3.2. CoAP Pub/sub Broker
A CoAP pubsub Broker is a CoAP Server that exposes a REST API for A CoAP pub/sub Broker is a CoAP Server that exposes a REST API for
clients to use to initiate publish-subscribe interactions. Avoiding clients to use to initiate publish-subscribe interactions. Avoiding
the need for direct reachability between clients, the broker only the need for direct reachability between clients, the broker only
needs to be reachable from all clients. The broker also needs to needs to be reachable from all clients. The broker also needs to
have sufficient resources (storage, bandwidth, etc.) to host CoAP have sufficient resources (storage, bandwidth, etc.) to host CoAP
resource services, and potentially buffer messages, on behalf of the resource services, and potentially buffer messages, on behalf of the
clients. clients.
3.3. CoAP pubsub Client 3.3. CoAP Pub/sub Client
A CoAP pubsub Client interacts with a CoAP pubsub Broker using the A CoAP pub/sub Client interacts with a CoAP pub/sub Broker using the
CoAP pubsub REST API defined in this document. Clients initiate CoAP pub/sub REST API defined in this document. Clients initiate
interactions with a CoAP pubsub broker. A data source (e.g., sensor interactions with a CoAP pub/sub broker. A data source (e.g., sensor
clients) can publish state updates to the broker and data sinks clients) can publish state updates to the broker and data sinks
(e.g., actuator clients) can read from or subscribe to state updates (e.g., actuator clients) can read from or subscribe to state updates
from the broker. Application clients can make use of both publish from the broker. Application clients can make use of both publish
and subscribe in order to exchange state updates with data sources and subscribe in order to exchange state updates with data sources
and data sinks. and data sinks.
3.4. CoAP pubsub Topic 3.4. CoAP Pub/sub Topic
The clients and broker use topics to identify a particular resource The clients and broker use topics to identify a particular resource
or object in a publish-subscribe system. Topics are conventionally or object in a publish-subscribe system. Topics are conventionally
formed as a hierarchy, e.g. "/sensors/weather/barometer/pressure" or formed as a hierarchy, e.g. "/sensors/weather/barometer/pressure" or
"EP-33543/sen/3303/0/5700". The topics are hosted at the broker and "EP-33543/sen/3303/0/5700". The topics are hosted at the broker and
all the clients using the broker share the same namespace for topics. all the clients using the broker share the same namespace for topics.
Every CoAP pubsub topic has a link, consisting of a reference path on Every CoAP pub/sub topic has a link, consisting of a reference path
the broker using URI path [RFC3986] construction and link attributes on the broker using URI path [RFC3986] construction and link
[RFC6690]. Every topic is associated with zero or more stored attributes [RFC6690]. Every topic is associated with zero or more
representations with a content-format specified in the link. A CoAP stored representations with a content-format specified in the link.
pubsub topic value may alternatively be a collection of one or more A CoAP pub/sub topic value may alternatively be a collection of one
sub-topics, consisting of links to the sub-topic URIs and indicated or more sub-topics, consisting of links to the sub-topic URIs and
by a link-format content-format. indicated by a link-format content-format.
3.5. Brokerless pubsub 3.5. Brokerless Pub/sub
Figure 2 shows an arrangement for using CoAP pubsub in a "brokerless" Figure 2 shows an arrangement for using CoAP pub/sub in a
configuration between peer nodes. Nodes in a brokerless system may "brokerless" configuration between peer nodes. Nodes in a brokerless
act as both broker and client. The Broker interface in a brokerless system may act as both broker and client. The Broker interface in a
node may be pre-configured with topics that expose services and brokerless node may be pre-configured with topics that expose
resources. Brokerless peer nodes can be mixed with client and broker services and resources. Brokerless peer nodes can be mixed with
nodes in a system with full interoperability. client and broker nodes in a system with full interoperability.
Peer pubsub Peer Peer pub/sub Peer
+-------+ | +-------+ +-------+ | +-------+
| CoAP | | | CoAP | | CoAP | | | CoAP |
|pubsub |---------|---------|pubsub | |pub/sub|---------|---------|pub/sub|
|Client | | |Broker | |Client | | |Broker |
+-------+ | +-------+ +-------+ | +-------+
| CoAP | | | CoAP | | CoAP | | | CoAP |
|pubsub |---------|---------|pubsub | |pub/sub|---------|---------|pub/sub|
|Broker | | |Client | |Broker | | |Client |
+-------+ | +-------+ +-------+ | +-------+
Figure 2: Brokerless pubsub Figure 2: Brokerless pub/sub
4. CoAP pubsub REST API 4. CoAP Pub/sub REST API
This section defines the REST API exposed by a CoAP pubsub Broker to This section defines the REST API exposed by a CoAP pub/sub Broker to
pubsub Clients. The examples throughout this section assume the use pub/sub Clients. The examples throughout this section assume the use
of CoAP [RFC7252]. A CoAP pubsub Broker implementing this of CoAP [RFC7252]. A CoAP pub/sub Broker implementing this
specification SHOULD support the DISCOVERY, CREATE, PUBLISH, specification SHOULD support the DISCOVERY, CREATE, PUBLISH,
SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE operations defined in this SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE operations defined in this
section. Optimized implementations MAY support a subset of the section. Optimized implementations MAY support a subset of the
operations as required by particular constrained use cases. operations as required by particular constrained use cases.
4.1. DISCOVERY 4.1. DISCOVERY
CoAP pubsub Clients discover CoAP pubsub Brokers by using CoAP Simple CoAP pub/sub Clients discover CoAP pub/sub Brokers by using CoAP
Discovery or through a Resource Directory (RD) Simple Discovery or through a Resource Directory (RD)
[I-D.ietf-core-resource-directory]. A CoAP pubsub Broker SHOULD [I-D.ietf-core-resource-directory]. A CoAP pub/sub Broker SHOULD
indicate its presence and availability on a network by exposing a indicate its presence and availability on a network by exposing a
link to the entry point of its pubsub API at its .well-known/core link to the entry point of its pub/sub API at its .well-known/core
location [RFC6690]. A CoAP pubsub broker MAY register its pubsub location [RFC6690]. A CoAP pub/sub broker MAY register its pub/sub
REST API entry point with a Resource Directory. Figure 3 shows an REST API entry point with a Resource Directory. Figure 3 shows an
example of a client discovering a local pubsub API using CoAP Simple example of a client discovering a local pub/sub API using CoAP Simple
Discovery. A broker wishing to advertise the CoAP pubsub API for Discovery. A broker wishing to advertise the CoAP pub/sub API for
Simple Discovery or through a Resource Directory MUST use the link Simple Discovery or through a Resource Directory MUST use the link
relation rt=core.ps. A broker MAY advertise its supported content relation rt=core.ps. A broker MAY advertise its supported content
formats and other attributes in the link to its pubsub API. formats and other attributes in the link to its pub/sub API.
A CoAP pubsub Broker MAY offer a topic discovery entry point to A CoAP pub/sub Broker MAY offer a topic discovery entry point to
enable Clients to find topics of interest, either by topic name or by enable Clients to find topics of interest, either by topic name or by
link attributes which may be registered when the topic is created. link attributes which may be registered when the topic is created.
Figure 4 shows an example of a client looking for a topic with a Figure 4 shows an example of a client looking for a topic with a
resource type (rt) of "temperature" using Discover. The client then resource type (rt) of "temperature" using Discover. The client then
receives the URI of the resource and its content-format. A pubsub receives the URI of the resource and its content-format. A pub/sub
broker wishing to advertize topic discovery MUST use the relation broker wishing to advertize topic discovery MUST use the relation
rt=core.ps.discover in the link. rt=core.ps.discover in the link.
A CoAP pubsub Broker MAY expose the Discover interface through the A CoAP pub/sub Broker MAY expose the Discover interface through the
.well-known/core resource. Links to topics may be exposed at .well- .well-known/core resource. Links to topics may be exposed at .well-
known/core in addition to links to the pubsub API. Figure 5 shows an known/core in addition to links to the pub/sub API. Figure 5 shows
example of topic discovery through .well-known/core. an example of topic discovery through .well-known/core.
The DISCOVER interface is specified as follows: The DISCOVER interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: GET Method: GET
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
Content-Format: application/link-format Content-Format: application/link-format
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content" with an application/link-format payload Success: 2.05 "Content" with an application/link-format payload
containing one or more matching entries for the broker resource. containing one or more matching entries for the broker resource.
A pubsub broker SHOULD use the value "/ps/" for the base URI of A pub/sub broker SHOULD use the value "/ps/" for the base URI of
the pubsub API wherever possible. the pub/sub API wherever possible.
Failure: 4.04 "Not Found" is returned in case no matching entry is Failure: 4.04 "Not Found" is returned in case no matching entry is
found for a unicast request. found for a unicast request.
Failure: 4.00 "Bad Request" is returned in case of a malformed Failure: 4.00 "Bad Request" is returned in case of a malformed
request for a unicast request. request for a unicast request.
Failure: No error response to a multicast request. Failure: No error response to a multicast request.
Client Broker Client Broker
| | | |
| ------ GET /.well-known/core?rt=core.ps ---->>| | ------ GET /.well-known/core?rt=core.ps ---->>|
| -- Content-Format: application/link-format ---| | -- Content-Format: application/link-format ---|
| | | |
| <<--- 2.05 Content | | <<--- 2.05 Content |
| </ps/>;rt=core.ps;rt=core.ps.discover;ct=40 --| | </ps/>;rt=core.ps;rt=core.ps.discover;ct=40 --|
| | | |
Figure 3: Example of DISCOVER pubsub function Figure 3: Example of DISCOVER pub/sub function
Client Broker Client Broker
| | | |
| ---------- GET /ps/?rt="temperature" ------->>| | ---------- GET /ps/?rt="temperature" ------->>|
| Content-Format: application/link-format | | Content-Format: application/link-format |
| | | |
| <<-- 2.05 Content | | <<-- 2.05 Content |
| </ps/currentTemp>;rt="temperature";ct=50 ---| | </ps/currentTemp>;rt="temperature";ct=50 ---|
| | | |
skipping to change at page 8, line 29 skipping to change at page 8, line 29
| Content-Format: application/link-format | | Content-Format: application/link-format |
| | | |
| <<-- 2.05 Content | | <<-- 2.05 Content |
| </ps/currentTemp>;rt="temperature";ct=50 ---| | </ps/currentTemp>;rt="temperature";ct=50 ---|
| | | |
Figure 5: Example of DISCOVER topic Figure 5: Example of DISCOVER topic
4.2. CREATE 4.2. CREATE
A CoAP pubsub broker MAY allow Clients to create new topics on the A CoAP pubsub broker SHOULD allow Clients to create new topics on the
broker using CREATE. A client wishing to create a topic MUST use broker using CREATE. Some exceptions are for fixed brokerless
CoAP POST to the pubsub API with a payload indicating the desired devices and pre-configured brokers in dedicated installations. A
topic. The topic specification sent in the payload MUST use a client wishing to create a topic MUST use CoAP POST to the pubsub API
supported serialization of the CoRE link format [RFC6690]. The with a payload indicating the desired topic. The topic specification
target of the link MUST be a URI formatted string. The client MUST sent in the payload MUST use a supported serialization of the CoRE
indicate the desired content format for publishes to the topic by link format [RFC6690]. The target of the link MUST be a URI
using the ct (Content Format) link attribute in the link-format formatted string. The client MUST indicate the desired content
payload. The client MAY indicate the lifetime of the topic by format for publishes to the topic by using the ct (Content Format)
including the Max-Age option in the CREATE request. link attribute in the link-format payload. The client MAY indicate
the lifetime of the topic by including the Max-Age option in the
CREATE request.
A Broker MUST return a response code of "2.01 Created" if the topic A Broker MUST return a response code of "2.01 Created" if the topic
is created and return the URI path of the created topic via Location- is created and return the URI path of the created topic via Location-
Path options. The broker MUST return the appropriate 4.xx response Path options. The broker MUST return the appropriate 4.xx response
code indicating the reason for failure if a new topic can not be code indicating the reason for failure if a new topic can not be
created. Broker SHOULD remove topics if the Max-Age of the topic is created. Broker SHOULD remove topics if the Max-Age of the topic is
exceeded without any publishes to the topic. Broker SHOULD retain a exceeded without any publishes to the topic. Broker SHOULD retain a
topic indefinitely if the Max-Age option is elided or is set to zero topic indefinitely if the Max-Age option is elided or is set to zero
upon topic creation. The lifetime of a topic MUST be refreshed upon upon topic creation. The lifetime of a topic MUST be refreshed upon
create operations with a target of an existing topic. create operations with a target of an existing topic.
skipping to change at page 9, line 21 skipping to change at page 9, line 21
as shown in Figure 7. as shown in Figure 7.
The CREATE interface is specified as follows: The CREATE interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: POST Method: POST
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
Content-Format: application/link-format Content-Format: application/link-format
Payload: The desired topic to CREATE Payload: The desired topic to CREATE
skipping to change at page 10, line 33 skipping to change at page 10, line 33
| | | |
| <---------------- 2.01 Created ---------------| | <---------------- 2.01 Created ---------------|
| Location: /ps/mainTopic/subTopic | | Location: /ps/mainTopic/subTopic |
| | | |
| | | |
Figure 7: Example of CREATE sub-topic Figure 7: Example of CREATE sub-topic
4.3. PUBLISH 4.3. PUBLISH
A CoAP pubsub broker MAY allow clients to PUBLISH to topics on the A CoAP pub/sub broker MAY allow clients to PUBLISH to topics on the
broker. A client MAY use the PUT or the POST method to publish state broker. A client MAY use the PUT or the POST method to publish state
updates to the CoAP pubsub Broker. A client MUST use the content updates to the CoAP pub/sub Broker. A client MUST use the content
format specified upon creation of a given topic to publish updates to format specified upon creation of a given topic to publish updates to
that topic. The broker MUST reject publish operations which do not that topic. The broker MUST reject publish operations which do not
use the specified content format. A CoAP client publishing on a use the specified content format. A CoAP client publishing on a
topic MAY indicate the maximum lifetime of the value by including the topic MAY indicate the maximum lifetime of the value by including the
Max-Age option in the publish request. The broker MUST return a Max-Age option in the publish request. The broker MUST return a
response code of "2.04 Changed" if the publish is accepted. A Broker response code of "2.04 Changed" if the publish is accepted. A Broker
MAY return a "4.04 Not Found" if the topic does not exist. A broker MAY return a "4.04 Not Found" if the topic does not exist. A broker
MAY return "4.29 Too Many Requests" if simple flow control as MAY return "4.29 Too Many Requests" if simple flow control as
described in Section 7 is implemented. described in Section 7 is implemented.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
clients. clients.
The PUBLISH interface is specified as follows: The PUBLISH interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: PUT, POST Method: PUT, POST
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
Content-Format: Any valid CoAP content format Content-Format: Any valid CoAP content format
Payload: Representation of the topic value (CoAP resource state Payload: Representation of the topic value (CoAP resource state
skipping to change at page 13, line 7 skipping to change at page 13, line 7
| | | |
| | | |
| <--------------- 2.01 Created---------------- | | <--------------- 2.01 Created---------------- |
| Location: /ps/exa/mpl/e | | Location: /ps/exa/mpl/e |
| | | |
Figure 9: Example of CREATE on PUBLISH Figure 9: Example of CREATE on PUBLISH
4.4. SUBSCRIBE 4.4. SUBSCRIBE
A CoAP pubsub broker MAY allow Clients to subscribe to topics on the A CoAP pub/sub broker MAY allow Clients to subscribe to topics on the
Broker using CoAP Observe as described in [RFC7641]. A CoAP pubsub Broker using CoAP Observe as described in [RFC7641]. A CoAP pub/sub
Client wishing to Subscribe to a topic on a broker MUST use a CoAP Client wishing to Subscribe to a topic on a broker MUST use a CoAP
GET with the Observe option set to 0 (zero). The Broker MAY add the GET with the Observe option set to 0 (zero). The Broker MAY add the
client to a list of observers. The Broker MUST return a response client to a list of observers. The Broker MUST return a response
code of "2.05 Content" along with the most recently published value code of "2.05 Content" along with the most recently published value
if the topic contains a valid value and the broker can supply the if the topic contains a valid value and the broker can supply the
requested content format. The broker MUST reject Subscribe requests requested content format. The broker MUST reject Subscribe requests
on a topic if the content format of the request is not supported by on a topic if the content format of the request is not supported by
the content format the topic was created with. The broker MAY accept the content format the topic was created with. The broker MAY accept
Subscribe requests which specify content formats that the broker can Subscribe requests which specify content formats that the broker can
supply as alternate content formats to the content format the topic supply as alternate content formats to the content format the topic
skipping to change at page 13, line 46 skipping to change at page 13, line 46
The SUBSCRIBE interface is specified as follows: The SUBSCRIBE interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: GET Method: GET
Options: Observe:0 Options: Observe:0
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content". Successful subscribe, current value Success: 2.05 "Content". Successful subscribe, current value
skipping to change at page 14, line 48 skipping to change at page 14, line 48
| | Publish | | | Publish |
| ---------|----------- PUT /ps/topic1 "1033.3" --------> | | ---------|----------- PUT /ps/topic1 "1033.3" --------> |
| | Notify | | | Notify |
| | <---------- 2.05 Content Observe:11 --------- | | | <---------- 2.05 Content Observe:11 --------- |
| | | | | |
Figure 10: Example of SUBSCRIBE Figure 10: Example of SUBSCRIBE
4.5. UNSUBSCRIBE 4.5. UNSUBSCRIBE
If a CoAP pubsub broker allows clients to SUBSCRIBE to topics on the If a CoAP pub/sub broker allows clients to SUBSCRIBE to topics on the
broker, it MUST allow Clients to unsubscribe from topics on the broker, it MUST allow Clients to unsubscribe from topics on the
Broker using the CoAP Cancel Observation operation. A CoAP pubsub Broker using the CoAP Cancel Observation operation. A CoAP pub/sub
Client wishing to unsubscribe to a topic on a Broker MUST either use Client wishing to unsubscribe to a topic on a Broker MUST either use
CoAP GET with Observe using an Observe parameter of 1 or send a CoAP CoAP GET with Observe using an Observe parameter of 1 or send a CoAP
Reset message in response to a publish, as per [RFC7641]. Reset message in response to a publish, as per [RFC7641].
The UNSUBSCRIBE interface is specified as follows: The UNSUBSCRIBE interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: GET Method: GET
Options: Observe:1 Options: Observe:1
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content". Successful unsubscribe, current value Success: 2.05 "Content". Successful unsubscribe, current value
skipping to change at page 16, line 7 skipping to change at page 16, line 7
| | | |
| ----- GET /ps/topic1 Observe:1 Token:XX ----> | | ----- GET /ps/topic1 Observe:1 Token:XX ----> |
| | | |
| <------------- 2.05 Content ----------------- | | <------------- 2.05 Content ----------------- |
| | | |
Figure 11: Example of UNSUBSCRIBE Figure 11: Example of UNSUBSCRIBE
4.6. READ 4.6. READ
A CoAP pubsub broker MAY accept Read requests on a topic using the A CoAP pub/sub broker MAY accept Read requests on a topic using the
the CoAP GET method if the content format of the request matches the the CoAP GET method if the content format of the request matches the
content format the topic was created with. The broker MAY accept content format the topic was created with. The broker MAY accept
Read requests which specify content formats that the broker can Read requests which specify content formats that the broker can
supply as alternate content formats to the content format the topic supply as alternate content formats to the content format the topic
was registered with. The Broker MUST return a response code of "2.05 was registered with. The Broker MUST return a response code of "2.05
Content" along with the most recently published value if the topic Content" along with the most recently published value if the topic
contains a valid value and the broker can supply the requested contains a valid value and the broker can supply the requested
content format. If the topic was published with the Max-Age option, content format. If the topic was published with the Max-Age option,
the broker MUST set the Max-Age option in the valid response to the the broker MUST set the Max-Age option in the valid response to the
amount of time remaining for the topic to be valid since the last amount of time remaining for the topic to be valid since the last
skipping to change at page 16, line 33 skipping to change at page 16, line 33
the requested content format. the requested content format.
The READ interface is specified as follows: The READ interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: GET Method: GET
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content". Successful READ, current value included Success: 2.05 "Content". Successful READ, current value included
skipping to change at page 17, line 33 skipping to change at page 17, line 33
| | Read | | | Read |
| | --------------- GET /ps/topic1 -------------> | | | --------------- GET /ps/topic1 -------------> |
| | | | | |
| | <----------- 2.05 Content "1033.3" ---------- | | | <----------- 2.05 Content "1033.3" ---------- |
| | | | | |
Figure 12: Example of READ Figure 12: Example of READ
4.7. REMOVE 4.7. REMOVE
A CoAP pubsub broker MAY allow clientsremove a topics from the broker A CoAP pub/sub broker MAY allow clientsremove a topics from the
using the CoAP Delete method on the URI of the topic. The CoAP broker using the CoAP Delete method on the URI of the topic. The
pubsub Broker MUST return "2.02 Deleted" if the removal is CoAP pub/sub Broker MUST return "2.02 Deleted" if the removal is
successful. The broker MUST return the appropriate 4.xx response successful. The broker MUST return the appropriate 4.xx response
code indicating the reason for failure if the topic can not be code indicating the reason for failure if the topic can not be
removed. When a topic is removed for any reason, the Broker SHOULD removed. When a topic is removed for any reason, the Broker SHOULD
return the response code 4.04 Not Found and remove all of the return the response code 4.04 Not Found and remove all of the
observers from the list of observers as per as per [RFC7641] observers from the list of observers as per as per [RFC7641]
Section 3.2. If a topic which has sub-topics is removed, then all of Section 3.2. If a topic which has sub-topics is removed, then all of
its sub-topics MUST be recursively removed. its sub-topics MUST be recursively removed.
The REMOVE interface is specified as follows: The REMOVE interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: DELETE Method: DELETE
URI Template: {+ps}/{+topic}{?q*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
topic := The desired topic to return links for (optional). topic := The desired topic to return links for (optional).
q := Query Filter (optional). MAY contain a query filter list as q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1. per [RFC6690] Section 4.1.
Content-Format: None Content-Format: None
Response Payload: None Response Payload: None
skipping to change at page 18, line 39 skipping to change at page 18, line 39
Client Broker Client Broker
| | | |
| ------------- DELETE /ps/topic1 ------------> | | ------------- DELETE /ps/topic1 ------------> |
| | | |
| | | |
| <-------------- 2.02 Deleted ---------------- | | <-------------- 2.02 Deleted ---------------- |
| | | |
Figure 13: Example of REMOVE Figure 13: Example of REMOVE
5. CoAP pubsub Operation with Resource Directory 5. CoAP Pub/sub Operation with Resource Directory
A CoAP pubsub Broker may register the base URI, which is the REST API A CoAP pub/sub Broker may register the base URI, which is the REST
entry point for a pubsub service, with a Resource Directory. A API entry point for a pub/sub service, with a Resource Directory. A
pubsub Client may use an RD to discover a pubsub Broker. pub/sub Client may use an RD to discover a pub/sub Broker.
A CoAP pubsub Client may register links [RFC6690] with a Resource A CoAP pub/sub Client may register links [RFC6690] with a Resource
Directory to enable discovery of created pubsub topics. A pubsub Directory to enable discovery of created pub/sub topics. A pub/sub
Client may use an RD to discover pubsub Topics. A client which Client may use an RD to discover pub/sub Topics. A client which
registers pubsub Topics with an RD MUST use the context relation registers pub/sub Topics with an RD MUST use the context relation
(con) [I-D.ietf-core-resource-directory] to indicate that the context (con) [I-D.ietf-core-resource-directory] to indicate that the context
of the registered links is the pubsub Broker. of the registered links is the pub/sub Broker.
A CoAP pubsub Broker may alternatively register links to its topics A CoAP pub/sub Broker may alternatively register links to its topics
to a Resource Directory by triggering the RD to retrieve it's links to a Resource Directory by triggering the RD to retrieve it's links
from .well-known/core. In order to use this method, the links must from .well-known/core. In order to use this method, the links must
first be exposed in the .well-known/core of the pubsub broker. See first be exposed in the .well-known/core of the pub/sub broker. See
Section 4.1 in this document. Section 4.1 in this document.
The pubsub broker triggers the RD to retrieve its links by sending a The pub/sub broker triggers the RD to retrieve its links by sending a
POST with an empty payload to the .well-known/core of the Resource POST with an empty payload to the .well-known/core of the Resource
Directory. The RD server will then retrieve the links from the Directory. The RD server will then retrieve the links from the
.well-known/core of the pubsub broker and incorporate them into the .well-known/core of the pub/sub broker and incorporate them into the
Resource Directory. See [I-D.ietf-core-resource-directory] for Resource Directory. See [I-D.ietf-core-resource-directory] for
further details. further details.
6. Sleep-Wake Operation 6. Sleep-Wake Operation
CoAP pubsub provides a way for client nodes to sleep between CoAP pub/sub provides a way for client nodes to sleep between
operations, conserving energy during idle periods. This is made operations, conserving energy during idle periods. This is made
possible by shifting the server role to the broker, allowing the possible by shifting the server role to the broker, allowing the
broker to be always-on and respond to requests from other clients broker to be always-on and respond to requests from other clients
while a particular client is sleeping. while a particular client is sleeping.
For example, the broker will retain the last state update received For example, the broker will retain the last state update received
from a sleeping client, in order to supply the most recent state from a sleeping client, in order to supply the most recent state
update to other clients in response to read and subscribe operations. update to other clients in response to read and subscribe operations.
Likewise, the broker will retain the last state update received on Likewise, the broker will retain the last state update received on
skipping to change at page 20, line 9 skipping to change at page 20, line 9
retry. The broker MAY stop creating notifications from the publish retry. The broker MAY stop creating notifications from the publish
messages from this client and to this topic for the indicated time. messages from this client and to this topic for the indicated time.
If a client receives the 4.29 Response Code from the broker for a If a client receives the 4.29 Response Code from the broker for a
publish message to a topic, it MUST NOT send new publish messages to publish message to a topic, it MUST NOT send new publish messages to
the broker on the same topic before the time indicated in Max-Age has the broker on the same topic before the time indicated in Max-Age has
passed. passed.
8. Security Considerations 8. Security Considerations
CoAP pubsub re-uses CoAP [RFC7252], CoRE Resource Directory CoAP pub/sub re-uses CoAP [RFC7252], CoRE Resource Directory
[I-D.ietf-core-resource-directory], and Web Linking [RFC5988] and [I-D.ietf-core-resource-directory], and Web Linking [RFC5988] and
therefore the security considerations of those documents also apply therefore the security considerations of those documents also apply
to this specification. Additionally, a CoAP pubsub broker and the to this specification. Additionally, a CoAP pub/sub broker and the
clients SHOULD authenticate each other and enforce access control clients SHOULD authenticate each other and enforce access control
policies. A malicious client could subscribe to data it is not policies. A malicious client could subscribe to data it is not
authorized to or mount a denial of service attack against the broker authorized to or mount a denial of service attack against the broker
by publishing a large number of resources. The authentication can be by publishing a large number of resources. The authentication can be
performed using the already standardized DTLS offered mechanisms, performed using the already standardized DTLS offered mechanisms,
such as certificates. DTLS also allows communication security to be such as certificates. DTLS also allows communication security to be
established to ensure integrity and confidentiality protection of the established to ensure integrity and confidentiality protection of the
data exchanged between these relevant parties. Provisioning the data exchanged between these relevant parties. Provisioning the
necessary credentials, trust anchors and authorization policies is necessary credentials, trust anchors and authorization policies is
non-trivial and subject of ongoing work. non-trivial and subject of ongoing work.
The use of a CoAP pubsub broker introduces challenges for the use of The use of a CoAP pub/sub broker introduces challenges for the use of
end-to-end security between for example a client device on a sensor end-to-end security between for example a client device on a sensor
network and a client application running in a cloud-based server network and a client application running in a cloud-based server
infrastructure since brokers terminate the exchange. While running infrastructure since brokers terminate the exchange. While running
separate DTLS sessions from the client device to the broker and from separate DTLS sessions from the client device to the broker and from
broker to client application protects confidentially on those paths, broker to client application protects confidentially on those paths,
the client device does not know whether the commands coming from the the client device does not know whether the commands coming from the
broker are actually coming from the client application. Similarly, a broker are actually coming from the client application. Similarly, a
client application requesting data does not know whether the data client application requesting data does not know whether the data
originated on the client device. For scenarios where end-to-end originated on the client device. For scenarios where end-to-end
security is desirable the use of application layer security is security is desirable the use of application layer security is
skipping to change at page 20, line 46 skipping to change at page 20, line 46
guarantee to the client device that any request originated at the guarantee to the client device that any request originated at the
client application. Similarly, integrity protected sensor data from client application. Similarly, integrity protected sensor data from
a client device will also provide guarantee to the client application a client device will also provide guarantee to the client application
that the data originated on the client device itself. The protected that the data originated on the client device itself. The protected
data can also be verified by the intermediate broker ensuring that it data can also be verified by the intermediate broker ensuring that it
stores/caches correct request/response and no malicious messages/ stores/caches correct request/response and no malicious messages/
requests are accepted. The broker would still be able to perform requests are accepted. The broker would still be able to perform
aggregation of data/requests collected. aggregation of data/requests collected.
Depending on the level of trust users and system designers place in Depending on the level of trust users and system designers place in
the CoAP pubsub broker, the use of end-to-end object security is the CoAP pub/sub broker, the use of end-to-end object security is
RECOMMENDED as described in [I-D.palombini-ace-coap-pubsub-profile]. RECOMMENDED as described in [I-D.palombini-ace-coap-pubsub-profile].
When only end-to-end encryption is necessary and the CoAP Broker is When only end-to-end encryption is necessary and the CoAP Broker is
trusted, Payload Only Protection (Mode:PAYL) could be used. The trusted, Payload Only Protection (Mode:PAYL) could be used. The
Publisher would wrap only the payload before sending it to the broker Publisher would wrap only the payload before sending it to the broker
and set the option Content-Format to application/smpayl. Upon and set the option Content-Format to application/smpayl. Upon
receival, the Broker can read the unencrypted CoAP header to forward receival, the Broker can read the unencrypted CoAP header to forward
it to the subscribers. it to the subscribers.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 22, line 23 skipping to change at page 22, line 23
The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit
Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran
Selander, Mikko Majanen, and Olaf Bergmann for their contributions Selander, Mikko Majanen, and Olaf Bergmann for their contributions
and reviews. and reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/ and D. Orchard, "URI Template", RFC 6570,
RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6570>. editor.org/info/rfc6570>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252,
RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7252>. editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, DOI 10.17487/ Application Protocol (CoAP)", RFC 7641,
RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7641>. editor.org/info/rfc7641>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Resource Directory", draft-ietf-core-resource-directory-10 Amsuess, "CoRE Resource Directory", draft-ietf-core-
(work in progress), March 2017. resource-directory-12 (work in progress), October 2017.
[I-D.palombini-ace-coap-pubsub-profile] [I-D.palombini-ace-coap-pubsub-profile]
Palombini, F., "CoAP Pub-Sub Profile for Authentication Palombini, F., "CoAP Pub-Sub Profile for Authentication
and Authorization for Constrained Environments (ACE)", and Authorization for Constrained Environments (ACE)",
draft-palombini-ace-coap-pubsub-profile-00 (work in draft-palombini-ace-coap-pubsub-profile-01 (work in
progress), March 2017. progress), September 2017.
[I-D.selander-ace-object-security] [I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace- "Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-06 (work in progress), October 2016. object-security-06 (work in progress), October 2016.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5988>. editor.org/info/rfc5988>.
Authors' Addresses Authors' Addresses
Michael Koster Michael Koster
SmartThings SmartThings
Email: Michael.Koster@smartthings.com Email: Michael.Koster@smartthings.com
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 81 change blocks. 
149 lines changed or deleted 151 lines changed or added

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