draft-ietf-core-coap-pubsub-00.txt   draft-ietf-core-coap-pubsub-01.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: April 24, 2017 J. Jimenez Expires: September 13, 2017 J. Jimenez
Ericsson Ericsson
October 21, 2016 March 12, 2017
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-pubsub-00 draft-ietf-core-coap-pubsub-01
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 April 24, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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
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 Function Set . . . . . . . . . . . . . . . . . . 6 4. CoAP pubsub API . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DISCOVER . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. CoAP pubsub Operation with Resource Directory . . . . . . . . 17 5. CoAP pubsub Operation with Resource Directory . . . . . . . . 18
6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 18 6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 19
7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 18 7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 20 9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 21
9.2. Response Code value '2.04' . . . . . . . . . . . . . . . 20 9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 21
9.3. Response Code value '4.29' . . . . . . . . . . . . . . . 20 9.3. Response Code value '2.04' . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9.4. Response Code value '4.29' . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] supports The Constrained Application Protocol (CoAP) [RFC7252] supports
machine-to-machine communication across networks of constrained machine-to-machine communication across networks of constrained
devices. CoAP uses a request/response model where clients make devices. CoAP uses a request/response model where clients make
requests to servers in order to request actions on resources. requests to servers in order to request actions on resources.
Depending on the situation the same device may act either as a server Depending on the situation the same device may act either as a server
or a client. or a client.
skipping to change at page 3, line 40 skipping to change at page 3, line 41
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 function set: A group of well-known REST resources that CoAP pubsub service: A group of REST resources, as defined in this
together provide the CoAP pubsub service. document, which together implement the CoAP pubsub service.
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.
CoAP pubsub Client: A CoAP client that implements the CoAP pubsub CoAP pubsub Client: A CoAP client which is capable of publish or
function set. 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. subscriptions to publications. A topic is a valid CoAP URI as
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 interface which is hosted by the Broker. State information is pubsub 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 function of state updates between performs a store-and-forward of state update representations between
certain CoAP pubsub Clients. Clients Subscribe to state updates certain CoAP pubsub Clients. Clients Subscribe to topics upon which
which are Published by other Clients, and which are forwarded by the representations are Published by other Clients, which are forwarded
Broker to the subscribing clients. The CoAP pubsub Broker also acts by the Broker to the subscribing clients. A CoAP pubsub Broker may
as a REST proxy, retaining the last state update provided by clients be used as a REST resource proxy, retaining the last published
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
+-------+ | +-------+ |
| CoAP | | | CoAP | |
|pubsub |---------|------+ |pubsub |---------|------+
|Client | | | +-------+ |Client | | | +-------+
+-------+ | +----| CoAP | +-------+ | +----| CoAP |
| |pubsub | | |pubsub |
+-------+ | +----|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 interface for A CoAP pubsub Broker is a CoAP Server that exposes an API for clients
clients to use to initiate publish-subscribe interactions. Unlike to use to initiate publish-subscribe interactions. Avoiding the need
clients, the broker needs to be reachable by all clients. The broker for direct reachability between clients, the broker only needs to be
also needs to have sufficient resources (storage, bandwidth, etc.) to reachable from all clients. The broker also needs to have sufficient
host CoAP resources, and potentially buffer messages, on behalf of resources (storage, bandwidth, etc.) to host CoAP resource services,
the clients. 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 interface. Clients initiate all interactions with the CoAP pubsub API. Clients initiate interactions with a CoAP pubsub
CoAP pubsub broker. A data source (e.g., sensor clients) can publish broker. A data source (e.g., sensor clients) can publish state
state updates to the broker and data sinks (e.g., actuator clients) updates to the broker and data sinks (e.g., actuator clients) can
can read from or subscribe to state updates from the broker. read from or subscribe to state updates from the broker. Application
Application clients can make use of both publish and subscribe in clients can make use of both publish and subscribe in order to
order to exchange state updates with data sources and sinks. exchange state updates with data sources and 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.
A CoAP pubsub topic has a reference path using URI path [RFC3986] Every CoAP pubsub topic has a link, consisting of a reference path on
construction, link attributes [RFC6690], and a representation of a the broker using URI path [RFC3986] construction and link attributes
value with specified content-formats. A CoAP pubsub topic value may [RFC6690]. Every topic is associated with zero or more stored
alternatively be a collection of one or more sub-topics, consisting representations with a content-format specified in the link. A CoAP
of links to the sub-topic URIs and indicated by a link-format pubsub topic value may alternatively be a collection of one or more
content-format. sub-topics, consisting of links to the sub-topic URIs and indicated
by a link-format content-format.
3.5. Brokerless pubsub 3.5. Brokerless pubsub
Figure 2 shows an arrangement for using CoAP pubsub in a "brokerless" Figure 2 shows an arrangement for using CoAP pubsub in a "brokerless"
configuration between peer nodes. Nodes in a brokerless system act configuration between peer nodes. Nodes in a brokerless system may
as both broker and client. The Broker interface in a brokerless node act as both broker and client. The Broker interface in a brokerless
may be pre-configured with topics that expose services and resources. node may be pre-configured with topics that expose services and
Brokerless peer nodes can be mixed with client and broker nodes in a resources. Brokerless peer nodes can be mixed with client and broker
system with full interoperability. nodes in a system with full interoperability.
Peer pubsub Peer Peer pubsub Peer
+-------+ | +-------+ +-------+ | +-------+
| CoAP | | | CoAP | | CoAP | | | CoAP |
|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 Function Set 4. CoAP pubsub API
This section defines the interfaces between a CoAP pubsub Broker and This section defines the API exposed by a CoAP pubsub Broker to
pubsub Clients, which is called the CoAP pubsub Function Set. The pubsub Clients. The examples throughout this section assume the use
examples throughout this section assume the use of CoAP [RFC7252]. A of CoAP [RFC7252]. A CoAP pubsub Broker implementing this
CoAP pubsub Broker implementing this specification MUST support the specification MUST support the DISCOVERY, CREATE, PUBLISH, SUBSCRIBE,
DISCOVER, CREATE, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE UNSUBSCRIBE, READ, and REMOVE operations defined in this section.
operations defined in this section.
4.1. DISCOVER 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 function set at its .well-known/core location link to its pubsub API at its .well-known/core location [RFC6690]. A
[RFC6690]. A CoAP pubsub broker MAY register its pubsub function set CoAP pubsub broker MAY register its pubsub API location with a
location with a Resource Directory. Figure 3 shows an example of a Resource Directory. Figure 3 shows an example of a client
client discovering a local pubsub Function Set using CoAP Simple discovering a local pubsub API using CoAP Simple Discovery. A broker
Discovery. A broker wishing to advertise the CoAP pubsub Function wishing to advertise the CoAP pubsub API for Simple Discovery or
Set for Simple Discovery or through a Resource Directory MUST use the through a Resource Directory MUST use the link relation rt=core.ps.
link relation rt="core.ps". A broker MAY advertise its supported A broker MAY advertise its supported content formats and other
content formats and other attributes in the link to its pubsub attributes in the link to its pubsub API.
function set.
A CoAP pubsub Broker MAY offer the Discover interface to enable A CoAP pubsub Broker MAY offer a topic discovery API to enable
Clients to find topics of interest, either by topic name or by link Clients to find topics of interest, either by topic name or by link
attributes which may be registered when the topic is created. 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" in the pubsub function set /ps resource type (rt) of "temperature" using Discover. The client then
using the Discover interface. The client then receives the URI of receives the URI of the resource and its content-format. A pubsub
the resource and its content-format. broker wishing to advertize topic discovery MUST use the relation
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 function set. Figure 5 known/core in addition to links to the pubsub API. Figure 5 shows an
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: /.well-known/core
URI Template: /{+ps/}{topic}{/topic*}{?q*} URI Template: /{+ps/}{topic}{/topic*}{?q*}
skipping to change at page 7, line 4 skipping to change at page 6, line 51
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: /.well-known/core
URI Template: /{+ps/}{topic}{/topic*}{?q*} URI Template: /{+ps/}{topic}{/topic*}{?q*}
URI Template Variables: URI Template Variables:
/.well-known/core := for discovering the pubsub function set /.well-known/core := for discovering the pubsub API (optional)
(optional)
ps := pubsub Function Set path (optional). The path of the ps := pubsub API path (optional). The base URI path of the
pubsub Function Set, as obtained from discovery, used to pubsub API, as obtained from discovery, used to discover
discover topics. 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 per [RFC6690] Section 4.1. as 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 function set A pubsub broker SHOULD use the value "/ps/" for the base URI of
URI wherever possible. the pubsub 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 "</ps/>;rt="core.ps";ct=40 ---| | <<--- 2.05 Content |
| </ps/>;rt=core.ps;rt=core.ps.discover;ct=40 --|
| | | |
Figure 3: Example of DISCOVER pubsub function Figure 3: Example of DISCOVER pubsub 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 ---|
| | | |
Figure 4: Example of DISCOVER topic Figure 4: Example of DISCOVER topic
Client Broker Client Broker
| | | |
| -------- GET /.well-known/core?ct=50 -------->| | -------- GET /.well-known/core?ct=50 ------->>|
| 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 topics on the broker using the CREATE interface. A Clients create new topics on the broker using CREATE. A client
client wishing to create a topic MUST use CoAP POST to the pubsub wishing to create a topic MUST use CoAP POST to the pubsub API with a
function set location with a payload indicating the desired topic. payload indicating the desired topic. The topic specification sent
The topic specification sent in the payload MUST use a supported in the payload MUST use a supported serialization of the CoRE link
serialization of the CoRE link format [RFC6690]. The target of the format [RFC6690]. The target of the link MUST be a URI formatted
link MUST be a URI formatted string. The client MUST indicate the string. The client MUST indicate the desired content format for
desired content format for publishes to the topic by using the ct publishes to the topic by using the ct (Content Format) link
(Content Format) link attribute in the link-format payload. The attribute in the link-format payload. The client MAY indicate the
client MAY indicate the lifetime of the topic by including the Max- lifetime of the topic by including the Max-Age option in the CREATE
Age option in the CREATE request. Broker MUST return a response code request.
of "2.01 Created" if the topic is created and return the created
relative URI path via Location-Path options. The broker MUST return A Broker MUST return a response code of "2.01 Created" if the topic
the appropriate 4.xx response code indicating the reason for failure is created and return the URI path of the created topic via Location-
if a new topic can not be created. Broker SHOULD remove topics if Path options. The broker MUST return the appropriate 4.xx response
the Max-Age of the topic is exceeded without any publishes to the code indicating the reason for failure if a new topic can not be
topic. Broker SHOULD retain a topic indefinitely if the Max-Age created. Broker SHOULD remove topics if the Max-Age of the topic is
option is elided or is set to zero upon topic creation. The lifetime exceeded without any publishes to the topic. Broker SHOULD retain a
of a topic MUST be refreshed upon create operations with a target of topic indefinitely if the Max-Age option is elided or is set to zero
an existing topic. upon topic creation. The lifetime of a topic MUST be refreshed upon
create operations with a target of an existing topic.
Topics may be created as sub-topics of other topics. A client MAY Topics may be created as sub-topics of other topics. A client MAY
create a topic with a ct (Content Format) link attribute value which create a topic with a ct (Content Format) link attribute value which
describes a supported serialization of the CoRE link format [RFC6690] describes a supported serialization of the CoRE link format [RFC6690]
such as application/link-format (ct=40) or its JSON or CBOR such as application/link-format (ct=40) or its JSON or CBOR
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}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. A pubsub as obtained from discovery. A pubsub broker SHOULD use the
broker SHOULD use the value "ps" for this variable whenever value "ps" for this variable whenever possible.
possible.
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 34 skipping to change at page 10, line 34
| <---------------- 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 Client uses the PUBLISH interface for updating topics
on the broker. The client MUST use the PUT method to publish state on the broker. A client MAY use the PUT or the POST method to
updates to the CoAP pubsub Broker. A client MUST use the content publish state updates to the CoAP pubsub Broker. A client MUST use
format specified upon creation of a given topic to publish updates to the content format specified upon creation of a given topic to
that topic. The broker MUST reject publish operations which do not publish updates to that topic. The broker MUST reject publish
use the specified content format. A CoAP client publishing on a operations which do not use the specified content format. A CoAP
topic MAY indicate the maximum lifetime of the value by including the client publishing on a topic MAY indicate the maximum lifetime of the
Max-Age option in the publish request. The broker MUST return a value by including the Max-Age option in the publish request. The
response code of "2.04 Changed" if the publish is accepted or "4.04 broker MUST return a response code of "2.04 Changed" if the publish
Not Found" if the topic does not exist. A broker MAY return "4.29 is accepted. A Broker MAY return a "4.04 Not Found" if the topic
Too Many Requests" if simple flow control as described in Section 7 does not exist. A broker MAY return "4.29 Too Many Requests" if
is implemented. simple flow control as described in Section 7 is implemented.
The Broker MUST notify all clients subscribed on a particular topic A Broker MUST accept PUBLISH operations using the PUT method.
each time it receives a publish on that topic. An example is shown PUBLISH operations using the PUT method replace any stored
in Figure 9. If a client publishes to a broker with the Max-Age representation associated with the topic, with the supplied
option, the broker MUST include the same value for the Max-Age option representation. A Broker MAY reject, or delay responses to, PUT
in all notifications. A broker MUST use CoAP Notification as requests to a topic while pending resolution of notifications to
described in [RFC7641] to notify subscribed clients. subscribers from previous PUT requests.
Create on PUBLISH: A Broker MAY accept PUBLISH operations to new
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
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-
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
created, the Broker MUST return the response "2.01 Created" with the
URI of the created topic, including all of the created path segments,
returned via the Location-Path option.
A Broker MAY accept PUBLISH operations using the POST method. If a
broker accepts PUBLISH using POST it MAY store an ordered list of
published representations, with an element of the list for each
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
which have been delivered to all subscribers or which have timed out.
A Broker MAY retain at least one most recently published
representation to return in response to SUBSRCIBE and READ requests.
A Broker MUST make a best-effort attempt to notify all clients
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
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
CoAP Notification as described in [RFC7641] to notify subscribed
clients.
The PUBLISH interface is specified as follows: The PUBLISH interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: PUT Method: PUT, POST
URI Template: /{+ps/}{topic}{/topic*} URI Template: /{+ps/}{topic}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. as obtained from discovery.
topic := The desired topic to publish on. topic := The desired topic to publish on.
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.04 "Changed". Successful publish, topic is updated Success: 2.04 "Changed". Successful publish, topic is updated
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.29 "Too Many Requests". The client should slow down the Failure: 4.29 "Too Many Requests". The client should slow down the
rate of publish messages for this topic (see Section 7). rate of publish messages for this topic (see Section 7).
Figure 8 shows an example of a new value being successfully published Figure 8 shows an example of a new value being successfully published
to the topic "topic1". See Figure 9 for an example of a broker to the topic "topic1". See Figure 10 for an example of a broker
forwarding a message from a publishing client to a subscribed client. forwarding a message from a publishing client to a subscribed client.
Client Broker Client Broker
| | | |
| ---------- PUT /ps/topic1 "1033.3" --------> | | ---------- PUT /ps/topic1 "1033.3" --------> |
| | | |
| | | |
| <--------------- 2.04 Changed---------------- | | <--------------- 2.04 Changed---------------- |
| | | |
Figure 8: Example of PUBLISH Figure 8: Example of PUBLISH
Client Broker
| |
| -------- PUT /ps/exa/mpl/e "1033.3" -------> |
| |
| |
| <--------------- 2.04 Created---------------- |
| Location: /ps/exa/mpl/e |
| |
Figure 9: Example of CREATE on PUBLISH
4.4. SUBSCRIBE 4.4. SUBSCRIBE
CoAP pubsub Clients subscribe to topics on the Broker using CoAP CoAP pubsub Clients subscribe to topics on the Broker using CoAP
Observe as described in [RFC7641]. A CoAP pubsub Client wishing to Observe as described in [RFC7641]. A CoAP pubsub Client wishing to
Subscribe to a topic on a broker MUST use a CoAP GET with Observe Subscribe to a topic on a broker MUST use a CoAP GET with Observe
registration. The Broker MAY add the client to a list of observers. registration. The Broker MAY add the client to a list of observers.
The Broker MUST return a response code of "2.05 Content" along with The Broker MUST return a response code of "2.05 Content" along with
the most recently published value if the topic contains a valid value the most recently published value if the topic contains a valid value
and the broker can supply the requested content format. The broker and the broker can supply the requested content format. The broker
MUST accept Subscribe requests on a topic if the content format of MUST reject Subscribe requests on a topic if the content format of
the request matches the content format the topic was created with. the request is not supported by the content format the topic was
The broker MAY accept Subscribe requests which specify content created with. The broker MAY accept Subscribe requests which specify
formats that the broker can supply as alternate content formats to content formats that the broker can supply as alternate content
the content format the topic was registered with. If the topic was formats to the content format the topic was registered with. If the
published with the Max-Age option, the broker MUST set the Max-Age topic was published with the Max-Age option, the broker MUST set the
option in the valid response to the amount of time remaining for the Max-Age option in the valid response to the amount of time remaining
value to be valid since the last publish operation on that topic. for the value to be valid since the last publish operation on that
The Broker MUST return a response code of "2.04 No Content" if the topic. The Broker MUST return a response code of "2.04 No Content"
Max-Age of the previously stored value has expired. The Broker MUST if the Max-Age of the previously stored value has expired. The
return a response code "4.04 Not Found" if the topic does not exist Broker MUST return a response code "4.04 Not Found" if the topic does
or has been removed. The Broker MUST return a response code "4.15 not exist or has been removed. The Broker MUST return a response
Unsupported Content Format" if it can not return the requested code "4.15 Unsupported Content Format" if it can not return the
content format. If a Broker is unable to accept a new Subscription requested content format. If a Broker is unable to accept a new
on a topic, it SHOULD return the appropriate response code without Subscription on a topic, it SHOULD return the appropriate response
the Observe option as per as per [RFC7641] Section 4.1. There is no code without the Observe option as per as per [RFC7641] Section 4.1.
explicit maximum lifetime of a Subscription, thus a Broker may remove There is no explicit maximum lifetime of a Subscription, thus a
subscribers at any time. The Broker, upon removing a Subscriber, Broker may remove subscribers at any time. The Broker, upon removing
will transmit the appropriate response code without the Observe a Subscriber, will transmit the appropriate response code without the
option, as per [RFC7641] Section 4.2, to the removed Subscriber. Observe option, as per [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}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. as obtained from discovery.
topic := The desired topic to subscribe to. topic := The desired topic to subscribe to.
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.04 "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.
Figure 9 shows an example of Client2 subscribing to "topic1" and Figure 10 shows an example of Client2 subscribing to "topic1" and
receiving a response from the broker, with a subsequent notification. receiving a response from the broker, with a subsequent notification.
The subscribe response from the broker uses the last stored value The subscribe response from the broker uses the last stored value
associated with the topic1. The notification from the broker is sent associated with the topic1. The notification from the broker is sent
in response to the publish received from Client1. in response to the publish received from Client1.
Client1 Client2 Broker Client1 Client2 Broker
| | Subscribe | | | Subscribe |
| | ----- GET /ps/topic1 Observe:0 Token:XX ----> | | | ----- GET /ps/topic1 Observe:0 Token:XX ----> |
| | | | | |
| | <---------- 2.05 Content Observe:10---------- | | | <---------- 2.05 Content Observe:10---------- |
| | | | | |
| | | | | |
| | 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 9: 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 CoAP pubsub Clients unsubscribe from topics on the Broker using the
CoAP Cancel Observation operation. A CoAP pubsub Client wishing to CoAP Cancel Observation operation. A CoAP pubsub Client wishing to
unsubscribe to a topic on a Broker MUST either use CoAP GET with unsubscribe to a topic on a Broker MUST either use CoAP GET with
Observe using an Observe parameter of 1 or send a CoAP Reset message Observe using an Observe parameter of 1 or send a CoAP Reset message
in response to a publish, as per [RFC7641]. in response to a publish, as per [RFC7641].
The UNSUBSCRIBE interface is specified as follows: The UNSUBSCRIBE interface is specified as follows:
skipping to change at page 14, line 25 skipping to change at page 15, line 17
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}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. as obtained from discovery.
topic := The desired topic to unsubscribe from. topic := The desired topic to unsubscribe from.
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.04 "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 10 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.
Client Broker Client Broker
| | | |
| ----- GET /ps/topic1 Observe:1 Token:XX ----> | | ----- GET /ps/topic1 Observe:1 Token:XX ----> |
| | | |
| <------------- 2.05 Content ----------------- | | <------------- 2.05 Content ----------------- |
| | | |
Figure 10: 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 client wishing to obtain only the most recent published
value on a topic MAY use the READ interface. For reading, the client value on a topic MAY use the READ interface. For reading, the client
uses the CoAP GET method. The broker MUST accept Read requests on a uses the CoAP GET method. The broker MUST accept Read requests on a
topic if the content format of the request matches the content format topic if the content format of the request matches the content format
the topic was created with. The broker MAY accept Read requests the topic was created with. The broker MAY accept Read requests
which specify content formats that the broker can supply as alternate which specify content formats that the broker can supply as alternate
content formats to the content format the topic was registered with. content formats to the content format the topic was registered with.
skipping to change at page 15, line 45 skipping to change at page 16, line 36
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}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. as obtained from discovery.
topic := The desired topic to READ. topic := The desired topic to READ.
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.04 "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.
Figure 11 shows an example of a successful READ from topic1, followed Figure 12 shows an example of a successful READ from topic1, followed
by a Publish on the topic, followed at some time later by a read of by a Publish on the topic, followed at some time later by a read of
the updated value from the recent Publish. the updated value from the recent Publish.
Client1 Client2 Broker Client1 Client2 Broker
| | Read | | | Read |
| | --------------- GET /ps/topic1 -------------> | | | --------------- GET /ps/topic1 -------------> |
| | | | | |
| | <---------- 2.05 Content "1007.1"------------ | | | <---------- 2.05 Content "1007.1"------------ |
| | | | | |
| | | | | |
| | Publish | | | Publish |
| ---------|----------- PUT /ps/topic1 "1033.3" --------> | | ---------|----------- PUT /ps/topic1 "1033.3" --------> |
| | | | | |
| | | | | |
| | Read | | | Read |
| | --------------- GET /ps/topic1 -------------> | | | --------------- GET /ps/topic1 -------------> |
| | | | | |
| | <----------- 2.05 Content "1033.3" ---------- | | | <----------- 2.05 Content "1033.3" ---------- |
| | | | | |
Figure 11: 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 Client wishing to remove a topic MAY use the CoAP
Delete operation on the URI of the topic. The CoAP pubsub Broker Delete operation on the URI of the topic. The CoAP pubsub Broker
MUST return "2.02 Deleted" if the remove operation is successful. MUST return "2.02 Deleted" if the remove operation is successful.
The broker MUST return the appropriate 4.xx response code indicating The broker MUST return the appropriate 4.xx response code indicating
the reason for failure if the topic can not be removed. When a topic the reason for failure if the topic can not be removed. When a topic
is removed for any reason, the Broker SHOULD return the response code is removed for any reason, the Broker SHOULD return the response code
4.04 Not Found and remove all of the observers from the list of 4.04 Not Found and remove all of the observers from the list of
observers as per as per [RFC7641] Section 3.2. observers as per as per [RFC7641] Section 3.2. If a topic which has
sub-topics is removed, then all of 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}{/topic*}
URI Template Variables: URI Template Variables:
ps := pubsub Function Set path (mandatory). The path of the ps := pubsub API path (mandatory). The path of the pubsub API,
pubsub Function Set, as obtained from discovery. as obtained from discovery.
topic := The desired topic to REMOVE. topic := The desired topic to REMOVE.
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.
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 12 shows a successful remove of topic1. Figure 13 shows a successful remove of topic1.
Client Broker Client Broker
| | | |
| ------------- DELETE /ps/topic1 ------------> | | ------------- DELETE /ps/topic1 ------------> |
| | | |
| | | |
| <-------------- 2.02 Deleted ---------------- | | <-------------- 2.02 Deleted ---------------- |
| | | |
Figure 12: 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 a pubsub Function Set with a A CoAP pubsub Broker may register the base URI of a pubsub API with a
Resource Directory. A pubsub Client may use an RD to discover a Resource Directory. A pubsub Client may use an RD to discover a
pubsub Broker. 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.
skipping to change at page 20, line 32 skipping to change at page 21, line 24
9.1. Resource Type value 'core.ps' 9.1. Resource Type value 'core.ps'
o Attribute Value: core.ps o Attribute Value: core.ps
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.2. Response Code value '2.04' 9.2. Resource Type value 'core.ps.discover'
o Attribute Value: core.ps.discover
o Description: Section 4 of [[This document]]
o Reference: [[This document]]
o Notes: None
9.3. Response Code value '2.04'
o Response Code: 2.04 o Response Code: 2.04
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.04 response code.
o Reference: [[This document]] o Reference: [[This document]]
o Notes: None o Notes: None
9.3. 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
skipping to change at page 21, line 18 skipping to change at page 22, line 22
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] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-08 Resource Directory", draft-ietf-core-resource-directory-09
(work in progress), July 2016. (work in progress), October 2016.
[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.
[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/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 63 change blocks. 
181 lines changed or deleted 241 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/