draft-ietf-core-coap-pubsub-01.txt   draft-ietf-core-coap-pubsub-02.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: September 13, 2017 J. Jimenez Expires: January 5, 2018 J. Jimenez
Ericsson Ericsson
March 12, 2017 July 4, 2017
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-pubsub-01 draft-ietf-core-coap-pubsub-02
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 September 13, 2017. This Internet-Draft will expire on January 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 pubsub Architecture . . . . . . . . . . . . . . . . 4
3.2. CoAP pubsub Broker . . . . . . . . . . . . . . . . . . . 4 3.2. CoAP pubsub Broker . . . . . . . . . . . . . . . . . . . 4
3.3. CoAP pubsub Client . . . . . . . . . . . . . . . . . . . 5 3.3. CoAP pubsub Client . . . . . . . . . . . . . . . . . . . 5
3.4. CoAP pubsub Topic . . . . . . . . . . . . . . . . . . . . 5 3.4. CoAP pubsub Topic . . . . . . . . . . . . . . . . . . . . 5
3.5. Brokerless pubsub . . . . . . . . . . . . . . . . . . . . 5 3.5. Brokerless pubsub . . . . . . . . . . . . . . . . . . . . 5
4. CoAP pubsub API . . . . . . . . . . . . . . . . . . . . . . . 6 4. CoAP pubsub 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 pubsub 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.04' . . . . . . . . . . . . . . . 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
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] supports The Constrained Application Protocol (CoAP) [RFC7252] supports
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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 (pubsub): 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 pubsub service: A group of REST resources, as defined in this
document, which together implement the CoAP pubsub service. document, which together implement the required features of this
specification.
CoAP pubsub Broker: A server node capable of receiving messages CoAP pubsub 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. publications to satisfy future subscriptions and pending
notifications.
CoAP pubsub Client: A CoAP client which is capable of publish or CoAP pubsub 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 pubsub Architecture
Figure 1 shows the architecture of a CoAP pubsub service. CoAP Figure 1 shows the architecture of a CoAP pubsub service. CoAP
pubsub Clients interact with a CoAP pubsub Broker through the CoAP pubsub Clients interact with a CoAP pubsub Broker through the CoAP
pubsub API which is hosted by the Broker. State information is pubsub 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 pubsub 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 pubsub 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 pubsub 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 pubsub Broker
+-------+ | +-------+ |
skipping to change at page 4, line 42 skipping to change at page 4, line 45
+-------+ | +----|Broker | +-------+ | +----|Broker |
| CoAP | | | +-------+ | CoAP | | | +-------+
|pubsub |---------|------+ |pubsub |---------|------+
|Client | | |Client | |
+-------+ | +-------+ |
Figure 1: CoAP pubsub Architecture Figure 1: CoAP pubsub Architecture
3.2. CoAP pubsub Broker 3.2. CoAP pubsub Broker
A CoAP pubsub Broker is a CoAP Server that exposes an API for clients A CoAP pubsub Broker is a CoAP Server that exposes a REST API for
to use to initiate publish-subscribe interactions. Avoiding the need clients to use to initiate publish-subscribe interactions. Avoiding
for direct reachability between clients, the broker only needs to be the need for direct reachability between clients, the broker only
reachable from all clients. The broker also needs to have sufficient needs to be reachable from all clients. The broker also needs to
resources (storage, bandwidth, etc.) to host CoAP resource services, have sufficient resources (storage, bandwidth, etc.) to host CoAP
and potentially buffer messages, on behalf of the clients. resource services, and potentially buffer messages, on behalf of the
clients.
3.3. CoAP pubsub Client 3.3. CoAP pubsub Client
A CoAP pubsub Client interacts with a CoAP pubsub Broker using the A CoAP pubsub Client interacts with a CoAP pubsub Broker using the
CoAP pubsub API. Clients initiate interactions with a CoAP pubsub CoAP pubsub REST API defined in this document. Clients initiate
broker. A data source (e.g., sensor clients) can publish state interactions with a CoAP pubsub broker. A data source (e.g., sensor
updates to the broker and data sinks (e.g., actuator clients) can clients) can publish state updates to the broker and data sinks
read from or subscribe to state updates from the broker. Application (e.g., actuator clients) can read from or subscribe to state updates
clients can make use of both publish and subscribe in order to from the broker. Application clients can make use of both publish
exchange state updates with data sources and sinks. and subscribe in order to exchange state updates with data sources
and data sinks.
3.4. CoAP pubsub Topic 3.4. CoAP pubsub 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 pubsub topic has a link, consisting of a reference path on
the broker using URI path [RFC3986] construction and link attributes the broker using URI path [RFC3986] construction and link attributes
skipping to change at page 6, line 5 skipping to change at page 6, line 5
|pubsub |---------|---------|pubsub | |pubsub |---------|---------|pubsub |
|Client | | |Broker | |Client | | |Broker |
+-------+ | +-------+ +-------+ | +-------+
| CoAP | | | CoAP | | CoAP | | | CoAP |
|pubsub |---------|---------|pubsub | |pubsub |---------|---------|pubsub |
|Broker | | |Client | |Broker | | |Client |
+-------+ | +-------+ +-------+ | +-------+
Figure 2: Brokerless pubsub Figure 2: Brokerless pubsub
4. CoAP pubsub API 4. CoAP pubsub REST API
This section defines the API exposed by a CoAP pubsub Broker to This section defines the REST API exposed by a CoAP pubsub Broker to
pubsub Clients. The examples throughout this section assume the use pubsub Clients. The examples throughout this section assume the use
of CoAP [RFC7252]. A CoAP pubsub Broker implementing this of CoAP [RFC7252]. A CoAP pubsub Broker implementing this
specification MUST support the DISCOVERY, CREATE, PUBLISH, SUBSCRIBE, specification SHOULD support the DISCOVERY, CREATE, PUBLISH,
UNSUBSCRIBE, READ, and REMOVE operations defined in this section. SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE operations defined in this
section. Optimized implementations MAY support a subset of the
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 pubsub Clients discover CoAP pubsub Brokers by using CoAP Simple
Discovery or through a Resource Directory (RD) 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 pubsub 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 its pubsub API at its .well-known/core location [RFC6690]. A link to the entry point of its pubsub API at its .well-known/core
CoAP pubsub broker MAY register its pubsub API location with a location [RFC6690]. A CoAP pubsub broker MAY register its pubsub
Resource Directory. Figure 3 shows an example of a client REST API entry point with a Resource Directory. Figure 3 shows an
discovering a local pubsub API using CoAP Simple Discovery. A broker example of a client discovering a local pubsub API using CoAP Simple
wishing to advertise the CoAP pubsub API for Simple Discovery or Discovery. A broker wishing to advertise the CoAP pubsub API for
through a Resource Directory MUST use the link relation rt=core.ps. Simple Discovery or through a Resource Directory MUST use the link
A broker MAY advertise its supported content formats and other relation rt=core.ps. A broker MAY advertise its supported content
attributes in the link to its pubsub API. formats and other attributes in the link to its pubsub API.
A CoAP pubsub Broker MAY offer a topic discovery API to enable A CoAP pubsub Broker MAY offer a topic discovery entry point to
Clients to find topics of interest, either by topic name or by link enable Clients to find topics of interest, either by topic name or by
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 pubsub
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 pubsub 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 pubsub API. Figure 5 shows an
example of topic discovery through .well-known/core. 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: /.well-known/core URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: ps := pubsub REST API entry point
URI Template: /{+ps/}{topic}{/topic*}{?q*} (optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
URI Template Variables:
/.well-known/core := for discovering the pubsub API (optional)
ps := pubsub API path (optional). The base URI path of the
pubsub API, as obtained 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 q := Query Filter (optional). MAY contain a query filter list as
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 pubsub broker SHOULD use the value "/ps/" for the base URI of
the pubsub API wherever possible. the pubsub API wherever possible.
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
Clients create new topics on the broker using CREATE. A client A CoAP pubsub broker MAY allow Clients to create new topics on the
wishing to create a topic MUST use CoAP POST to the pubsub API with a broker using CREATE. A client wishing to create a topic MUST use
payload indicating the desired topic. The topic specification sent CoAP POST to the pubsub API with a payload indicating the desired
in the payload MUST use a supported serialization of the CoRE link topic. The topic specification sent in the payload MUST use a
format [RFC6690]. The target of the link MUST be a URI formatted supported serialization of the CoRE link format [RFC6690]. The
string. The client MUST indicate the desired content format for target of the link MUST be a URI formatted string. The client MUST
publishes to the topic by using the ct (Content Format) link indicate the desired content format for publishes to the topic by
attribute in the link-format payload. The client MAY indicate the using the ct (Content Format) link attribute in the link-format
lifetime of the topic by including the Max-Age option in the CREATE payload. The client MAY indicate the lifetime of the topic by
request. 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 19 skipping to change at page 9, line 19
serializations. If a topic is created which describes a link serializations. If a topic is created which describes a link
serialization, that topic may then have sub-topics created under it serialization, that topic may then have sub-topics created under it
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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery. A pubsub broker SHOULD use the
value "ps" for this variable whenever possible. q := Query Filter (optional). MAY contain a query filter list as
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
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created". Successful Creation of the topic Success: 2.01 "Created". Successful Creation of the topic
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
Failure: 4.03 "Forbidden". Topic already exists. Failure: 4.03 "Forbidden". Topic already exists.
Failure: 4.06 "Not Acceptable". Unsupported content format for Failure: 4.06 "Not Acceptable". Unsupported content format for
topic. topic.
Figure 6 shows an example of a topic called "topic1" being Figure 6 shows an example of a topic called "topic1" being
successfully created. successfully created.
Client Broker Client Broker
| | | |
| ---------- POST /ps "<topic1>;ct=50" -------->| | ---------- POST /ps/ "<topic1>;ct=50" -------->|
| | | |
| <---------------- 2.01 Created ---------------| | <---------------- 2.01 Created ---------------|
| Location: /ps/topic1 | | Location: /ps/topic1 |
| | | |
Figure 6: Example of CREATE topic Figure 6: Example of CREATE topic
Client Broker Client Broker
| | | |
| ------- POST /ps/ "<mainTopic>;ct=40" ------->| | ------- POST /ps/ "<mainTopic>;ct=40" ------->|
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 Client uses the PUBLISH interface for updating topics A CoAP pubsub broker MAY allow clients to PUBLISH to topics on the
on the broker. A client MAY use the PUT or the POST method to broker. A client MAY use the PUT or the POST method to publish state
publish state updates to the CoAP pubsub Broker. A client MUST use updates to the CoAP pubsub Broker. A client MUST use the content
the content format specified upon creation of a given topic to format specified upon creation of a given topic to publish updates to
publish updates to that topic. The broker MUST reject publish that topic. The broker MUST reject publish operations which do not
operations which do not use the specified content format. A CoAP use the specified content format. A CoAP client publishing on a
client publishing on a topic MAY indicate the maximum lifetime of the topic MAY indicate the maximum lifetime of the value by including the
value by including the Max-Age option in the publish request. The Max-Age option in the publish request. The broker MUST return a
broker MUST return a response code of "2.04 Changed" if the publish response code of "2.04 Changed" if the publish is accepted. A Broker
is accepted. A Broker MAY return a "4.04 Not Found" if the topic MAY return a "4.04 Not Found" if the topic does not exist. A broker
does not exist. A broker MAY return "4.29 Too Many Requests" if MAY return "4.29 Too Many Requests" if simple flow control as
simple flow control as described in Section 7 is implemented. described in Section 7 is implemented.
A Broker MUST accept PUBLISH operations using the PUT method. A Broker MUST accept PUBLISH operations using the PUT method.
PUBLISH operations using the PUT method replace any stored PUBLISH operations using the PUT method replace any stored
representation associated with the topic, with the supplied representation associated with the topic, with the supplied
representation. A Broker MAY reject, or delay responses to, PUT representation. A Broker MAY reject, or delay responses to, PUT
requests to a topic while pending resolution of notifications to requests to a topic while pending resolution of notifications to
subscribers from previous PUT requests. subscribers from previous PUT requests.
Create on PUBLISH: A Broker MAY accept PUBLISH operations to new Create on PUBLISH: A Broker MAY accept PUBLISH operations to new
topics using the PUT method. If a Broker accepts a PUBLISH using PUT topics using the PUT method. If a Broker accepts a PUBLISH using PUT
to a topic that does not exist, the Broker MUST create the topic to a topic that does not exist, the Broker MUST create the topic
using the information in the PUT operation. The Broker MUST create a using the information in the PUT operation. The Broker MUST create a
topic with the URI-Path of the request, including all of the sub- topic with the URI-Path of the request, including all of the sub-
topics necessary, and create a topic link with the ct attribute set topics necessary, and create a topic link with the ct attribute set
to the content-format of the payload of the PUT request. If topic is to the content-format of the payload of the PUT request. If topic is
created, the Broker MUST return the response "2.01 Created" with the created, the Broker MUST return the response "2.01 Created" with the
URI of the created topic, including all of the created path segments, URI of the created topic, including all of the created path segments,
returned via the Location-Path option. returned via the Location-Path option.
A Broker MAY accept PUBLISH operations using the POST method. If a A Broker MAY accept PUBLISH operations using the POST method. If a
broker accepts PUBLISH using POST it MAY store an ordered list of broker accepts PUBLISH using POST it shall respond with the 2.04
published representations, with an element of the list for each Changed status code.
published representation. A Broker MAY reject, or delay responses
to, POST requests if the internal capacity to store representations
is exceeded.
A Broker MAY perform garbage collection of stored representations A Broker MAY perform garbage collection of stored representations
which have been delivered to all subscribers or which have timed out. which have been delivered to all subscribers or which have timed out.
A Broker MAY retain at least one most recently published A Broker MAY retain at least one most recently published
representation to return in response to SUBSRCIBE and READ requests. representation to return in response to SUBSRCIBE and READ requests.
A Broker MUST make a best-effort attempt to notify all clients A Broker MUST make a best-effort attempt to notify all clients
subscribed on a particular topic each time it receives a publish on subscribed on a particular topic each time it receives a publish on
that topic. An example is shown in Figure 10. If a client publishes that topic. An example is shown in Figure 10. If a client publishes
to a broker with the Max-Age option, the broker MUST include the same to a broker with the Max-Age option, the broker MUST include the same
value for the Max-Age option in all notifications. A broker MUST use value for the Max-Age option in all notifications. A broker MUST use
CoAP Notification as described in [RFC7641] to notify subscribed CoAP Notification as described in [RFC7641] to notify subscribed
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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery.
topic := The desired topic to publish on. q := Query Filter (optional). MAY contain a query filter list as
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
representation) in the indicated content format representation) in the indicated content format
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created". Successful publish, topic is created Success: 2.01 "Created". Successful publish, topic is created
skipping to change at page 12, line 44 skipping to change at page 12, line 44
| <--------------- 2.04 Changed---------------- | | <--------------- 2.04 Changed---------------- |
| | | |
Figure 8: Example of PUBLISH Figure 8: Example of PUBLISH
Client Broker Client Broker
| | | |
| -------- PUT /ps/exa/mpl/e "1033.3" -------> | | -------- PUT /ps/exa/mpl/e "1033.3" -------> |
| | | |
| | | |
| <--------------- 2.04 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
CoAP pubsub Clients subscribe to topics on the Broker using CoAP A CoAP pubsub broker MAY allow Clients to subscribe to topics on the
Observe as described in [RFC7641]. A CoAP pubsub Client wishing to Broker using CoAP Observe as described in [RFC7641]. A CoAP pubsub
Subscribe to a topic on a broker MUST use a CoAP GET with Observe Client wishing to Subscribe to a topic on a broker MUST use a CoAP
registration. The Broker MAY add the client to a list of observers. GET with the Observe option set to 0 (zero). The Broker MAY add the
The Broker MUST return a response code of "2.05 Content" along with client to a list of observers. The Broker MUST return a response
the most recently published value if the topic contains a valid value code of "2.05 Content" along with the most recently published value
and the broker can supply the requested content format. The broker if the topic contains a valid value and the broker can supply the
MUST reject Subscribe requests on a topic if the content format of requested content format. The broker MUST reject Subscribe requests
the request is not supported by the content format the topic was on a topic if the content format of the request is not supported by
created with. The broker MAY accept Subscribe requests which specify the content format the topic was created with. The broker MAY accept
content formats that the broker can supply as alternate content Subscribe requests which specify content formats that the broker can
formats to the content format the topic was registered with. If the supply as alternate content formats to the content format the topic
topic was published with the Max-Age option, the broker MUST set the was registered with. If the topic was published with the Max-Age
Max-Age option in the valid response to the amount of time remaining option, the broker MUST set the Max-Age option in the valid response
for the value to be valid since the last publish operation on that to the amount of time remaining for the value to be valid since the
topic. The Broker MUST return a response code of "2.04 No Content" last publish operation on that topic. The Broker MUST return a
if the Max-Age of the previously stored value has expired. The response code of "2.07 No Content" if the Max-Age of the previously
Broker MUST return a response code "4.04 Not Found" if the topic does stored value has expired. The Broker MUST return a response code
not exist or has been removed. The Broker MUST return a response "4.04 Not Found" if the topic does not exist or has been removed.
code "4.15 Unsupported Content Format" if it can not return the The Broker MUST return a response code "4.15 Unsupported Content
requested content format. If a Broker is unable to accept a new Format" if it can not return the requested content format. If a
Subscription on a topic, it SHOULD return the appropriate response Broker is unable to accept a new Subscription on a topic, it SHOULD
code without the Observe option as per as per [RFC7641] Section 4.1. return the appropriate response code without the Observe option as
There is no explicit maximum lifetime of a Subscription, thus a per as per [RFC7641] Section 4.1. There is no explicit maximum
Broker may remove subscribers at any time. The Broker, upon removing lifetime of a Subscription, thus a Broker may remove subscribers at
a Subscriber, will transmit the appropriate response code without the any time. The Broker, upon removing a Subscriber, will transmit the
Observe option, as per [RFC7641] Section 4.2, to the removed appropriate response code without the Observe option, as per
Subscriber. [RFC7641] Section 4.2, to the removed Subscriber.
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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery.
topic := The desired topic to subscribe to. q := Query Filter (optional). MAY contain a query filter list as
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
included included
Success: 2.04 "No Content". Successful subscribe, value not Success: 2.07 "No Content". Successful subscribe, value not
included included
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.01 "Unauthorized". Authorization failure. Failure: 4.01 "Unauthorized". Authorization failure.
Failure: 4.04 "Not Found". Topic does not exist. Failure: 4.04 "Not Found". Topic does not exist.
Failure: 4.15 "Unsupported Content Format". Unsupported content Failure: 4.15 "Unsupported Content Format". Unsupported content
format. format.
skipping to change at page 14, line 45 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
CoAP pubsub Clients unsubscribe from topics on the Broker using the If a CoAP pubsub broker allows clients to SUBSCRIBE to topics on the
CoAP Cancel Observation operation. A CoAP pubsub Client wishing to broker, it MUST allow Clients to unsubscribe from topics on the
unsubscribe to a topic on a Broker MUST either use CoAP GET with Broker using the CoAP Cancel Observation operation. A CoAP pubsub
Observe using an Observe parameter of 1 or send a CoAP Reset message Client wishing to unsubscribe to a topic on a Broker MUST either use
in response to a publish, as per [RFC7641]. CoAP GET with Observe using an Observe parameter of 1 or send a CoAP
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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery.
topic := The desired topic to unsubscribe from. q := Query Filter (optional). MAY contain a query filter list as
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
included included
Success: 2.04 "No Content". Successful unsubscribe, value not Success: 2.07 "No Content". Successful unsubscribe, value not
included included
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.01 "Unauthorized". Authorization failure. Failure: 4.01 "Unauthorized". Authorization failure.
Failure: 4.04 "Not Found". Topic does not exist. Failure: 4.04 "Not Found". Topic does not exist.
Figure 11 shows an example of a client unsubscribe using the Figure 11 shows an example of a client unsubscribe using the
Observe=1 cancellation method. Observe=1 cancellation method.
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 client wishing to obtain only the most recent published A CoAP pubsub broker MAY accept Read requests on a topic using the
value on a topic MAY use the READ interface. For reading, the client the CoAP GET method if the content format of the request matches the
uses the CoAP GET method. The broker MUST accept Read requests on a content format the topic was created with. The broker MAY accept
topic if the content format of the request matches the content format Read requests which specify content formats that the broker can
the topic was created with. The broker MAY accept Read requests supply as alternate content formats to the content format the topic
which specify content formats that the broker can supply as alternate was registered with. The Broker MUST return a response code of "2.05
content formats to the content format the topic was registered with. Content" along with the most recently published value if the topic
The Broker MUST return a response code of "2.05 Content" along with contains a valid value and the broker can supply the requested
the most recently published value if the topic contains a valid value content format. If the topic was published with the Max-Age option,
and the broker can supply the requested content format. If the topic the broker MUST set the Max-Age option in the valid response to the
was published with the Max-Age option, the broker MUST set the Max- amount of time remaining for the topic to be valid since the last
Age option in the valid response to the amount of time remaining for publish. The Broker MUST return a response code of "2.07 No Content"
the topic to be valid since the last publish. The Broker MUST return if the Max-Age of the previously stored value has expired. The
a response code of "2.04 No Content" if the Max-Age of the previously Broker MUST return a response code "4.04 Not Found" if the topic does
stored value has expired. The Broker MUST return a response code not exist or has been removed. The Broker MUST return a response
"4.04 Not Found" if the topic does not exist or has been removed. code "4.15 Unsupported Content Format" if the broker can not return
The Broker MUST return a response code "4.15 Unsupported Content the requested content format.
Format" if the broker can not return 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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery.
topic := The desired topic to READ. q := Query Filter (optional). MAY contain a query filter list as
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
Success: 2.04 "No Content". Topic exists, value not included Success: 2.07 "No Content". Topic exists, value not included
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.01 "Unauthorized". Authorization failure. Failure: 4.01 "Unauthorized". Authorization failure.
Failure: 4.04 "Not Found". Topic does not exist. Failure: 4.04 "Not Found". Topic does not exist.
Failure: 4.15 "Unsupported Content Format". Unsupported content- Failure: 4.15 "Unsupported Content Format". Unsupported content-
format. format.
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 Client wishing to remove a topic MAY use the CoAP A CoAP pubsub broker MAY allow clientsremove a topics from the broker
Delete operation on the URI of the topic. The CoAP pubsub Broker using the CoAP Delete method on the URI of the topic. The CoAP
MUST return "2.02 Deleted" if the remove operation is successful. pubsub Broker MUST return "2.02 Deleted" if the removal is
The broker MUST return the appropriate 4.xx response code indicating successful. The broker MUST return the appropriate 4.xx response
the reason for failure if the topic can not be removed. When a topic code indicating the reason for failure if the topic can not be
is removed for any reason, the Broker SHOULD return the response code removed. When a topic is removed for any reason, the Broker SHOULD
4.04 Not Found and remove all of the observers from the list of return the response code 4.04 Not Found and remove all of the
observers as per as per [RFC7641] Section 3.2. If a topic which has observers from the list of observers as per as per [RFC7641]
sub-topics is removed, then all of its sub-topics MUST be recursively Section 3.2. If a topic which has sub-topics is removed, then all of
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}{/topic*} URI Template: {+ps}/{+topic}{?q*}
URI Template Variables: URI Template Variables: ps := pubsub REST API entry point
(optional). The entry point of the pubsub REST API, as obtained
from discovery, used to discover topics.
ps := pubsub API path (mandatory). The path of the pubsub API, topic := The desired topic to return links for (optional).
as obtained from discovery.
topic := The desired topic to REMOVE. q := Query Filter (optional). MAY contain a query filter list as
per [RFC6690] Section 4.1.
Content-Format: None Content-Format: None
Response Payload: None Response Payload: None
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.02 "Deleted". Successful remove Success: 2.02 "Deleted". Successful remove
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
skipping to change at page 18, line 39 skipping to change at page 18, line 41
| ------------- 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 pubsub Operation with Resource Directory
A CoAP pubsub Broker may register the base URI of a pubsub API with a A CoAP pubsub Broker may register the base URI, which is the REST API
Resource Directory. A pubsub Client may use an RD to discover a entry point for a pubsub service, with a Resource Directory. A
pubsub Broker. pubsub Client may use an RD to discover a pubsub Broker.
A CoAP pubsub Client may register links [RFC6690] with a Resource A CoAP pubsub Client may register links [RFC6690] with a Resource
Directory to enable discovery of created pubsub topics. A pubsub Directory to enable discovery of created pubsub topics. A pubsub
Client may use an RD to discover pubsub Topics. A client which Client may use an RD to discover pubsub Topics. A client which
registers pubsub Topics with an RD MUST use the context relation registers pubsub 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 pubsub Broker.
A CoAP pubsub Broker may alternatively register links to its topics A CoAP pubsub 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
skipping to change at page 20, line 47 skipping to change at page 20, line 47
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 pubsub broker, the use of end-to-end object security is
RECOMMENDED [I-D.selander-ace-object-security]. 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
This document registers one attribute value in the Resource Type This document registers one attribute value in the Resource Type
skipping to change at page 21, line 34 skipping to change at page 21, line 33
9.2. Resource Type value 'core.ps.discover' 9.2. Resource Type value 'core.ps.discover'
o Attribute Value: core.ps.discover o Attribute Value: core.ps.discover
o Description: Section 4 of [[This document]] o Description: Section 4 of [[This document]]
o Reference: [[This document]] o Reference: [[This document]]
o Notes: None o Notes: None
9.3. Response Code value '2.04' 9.3. Response Code value '2.07'
o Response Code: 2.04 o Response Code: 2.07
o Description: Add No Content response to GET to the existing o Description: Add No Content response to GET to the existing
definition of the 2.04 response code. definition of the 2.07 response code.
o Reference: [[This document]] o Reference: [[This document]]
o Notes: None o Notes: The server sends this code to the client to indicate that
the request was valid and accepted, but the responce may contain
an empty payload. It is comparable to and may be proxied with the
http 204 No Content status code.
9.4. Response Code value '4.29' 9.4. Response Code value '4.29'
o Response Code: 4.29 o Response Code: 4.29
o Description: This error code is used by a server to indicate that o Description: This error code is used by a server to indicate that
a client is making too many requests on a resource. a client is making too many requests on a resource.
o Reference: [[This document]] o Reference: [[This document]]
o Notes: None o Notes: None
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit
skipping to change at page 22, line 20 skipping to change at page 22, line 22
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
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-09
(work in progress), October 2016.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-06 (work in progress), October 2016.
[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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-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, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://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, and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/
DOI 10.17487/RFC6570, March 2012, RFC6570, March 2012,
<http://www.rfc-editor.org/info/rfc6570>. <http://www.rfc-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>. <http://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, Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
DOI 10.17487/RFC7252, June 2014, RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-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, Application Protocol (CoAP)", RFC 7641, DOI 10.17487/
DOI 10.17487/RFC7641, September 2015, RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>. <http://www.rfc-editor.org/info/rfc7641>.
11.2. Informative References 11.2. Informative References
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [I-D.ietf-core-resource-directory]
DOI 10.17487/RFC5988, October 2010, Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-10
(work in progress), March 2017.
[I-D.palombini-ace-coap-pubsub-profile]
Palombini, F., "CoAP Pub-Sub Profile for Authentication
and Authorization for Constrained Environments (ACE)",
draft-palombini-ace-coap-pubsub-profile-00 (work in
progress), March 2017.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-06 (work in progress), October 2016.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>. <http://www.rfc-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
 End of changes. 67 change blocks. 
205 lines changed or deleted 221 lines changed or added

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