One document matched: draft-koster-core-coap-pubsub-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>

<rfc category="std" ipr="trust200902" docName="draft-koster-core-coap-pubsub-01">

  <front>
  <title abbrev="Publish-Subscribe Broker for CoAP">Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)</title>

    <author fullname="Michael Koster" initials="M.K." surname="Koster">
      <organization>ARM Limited</organization>
      <address>
	    <email>Michael.Koster@arm.com</email>
      </address>
    </author>

    
    <author fullname="Ari Keranen" initials="A.K." surname="Keranen">
      <organization>Ericsson</organization>
      <address>
        <email>ari.keranen@ericsson.com</email>
      </address>
    </author>
	

<author fullname="Jaime Jimenez" initials="J.J." surname="Jimenez">
      <organization>Ericsson</organization>
      <address>
        <email>jaime.jimenez@ericsson.com</email>
      </address>
    </author>
	

    <date year="2015"/>
    <keyword>Internet-Draft</keyword>
    <keyword>CoRE</keyword>
    <keyword>CoAP</keyword>
    <keyword>Publish Subscribe</keyword>
    <abstract>

  <t>The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish-subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time.</t>
  
</abstract>

  </front>
  <middle>

<!-- ====================================================================== -->

<section anchor="introduction" title="Introduction">
<t>The Constrained Application Protocol (CoAP) <xref target="RFC7252"/> supports machine-to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources. Depending on the situation the same device may act either as a server or a client. </t>

<t>One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging energy from their environment. These devices have limited reachability because they spend most of their time in a sleeping state with no network connectivity. Devices may also have limited reachability due to certain middle-boxes, such as Network Address Translators (NATs) or firewalls. Such middle-boxes often prevent connecting to a device from the Internet unless the connection was initiated by the device. </t>

<t>This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP. The extensions enable publish-subscribe communication using a broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP. </t>

<!--
<t>The mechanisms specified in this document are meant to address key design requirements from earlier CoRE drafts covering sleepy node support and mirror server. </t>
-->

</section>

<!-- ====================================================================== -->

<section title="Terminology">
   <t>The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   specification are to be interpreted as described in <xref target="RFC2119"/>.</t>
   
   <t>This specification requires readers to be familiar with all the terms and concepts that are discussed in <xref target="RFC5988"/> and <xref target="RFC6690"/>. Readers should also be familiar with the terms and concepts discussed in <xref target="RFC7252"/> and <xref target="I-D.ietf-core-resource-directory"/>. The URI template format <xref target="RFC6570"/> is used to describe the REST interfaces defined in this specification.</t>

<t>This specification makes use of the following additional terminology:
<list style="hanging">

<t hangText="Publish-Subscribe (pub-sub):">A messaging paradigm where messages are published to a broker and potential receivers can subscribe to the broker to receive messages. The publishers do not (need to) know where the message will be eventually sent: the publications and subscriptions are matched by a broker and publications are delivered by the broker to subscribed receivers. </t>

<t hangText="CoAP-PubSub function set:">A group of well-known REST resources that together provide the CoAP-PubSub service.</t>

<t hangText="CoAP-PubSub Broker:">A server node capable of receiving messages (publications) from and sending messages to other nodes, and able to match subscriptions and publications in order to route messages to the right destinations. The broker can also temporarily store publications to satisfy future subscriptions. </t>

<t hangText="CoAP-PubSub Client:">A CoAP client that implements the CoAP-PubSub function set. </t>

<t hangText="Topic:">A unique identifier for a particular item being published and/or subscribed to. A broker uses the topics to match subscriptions to publications. </t>

</list>
</t>

</section>
	  
<!-- ====================================================================== -->

<section anchor="architecture" title="Architecture"> 

<section title="CoAP-PubSub Architecture">

<t><xref target="arch-fig"/> shows the architecture of a CoAP PubSub service. CoAP PubSub Clients interact with a CoAP PubSub Broker through the CoAP PubSub interface which is hosted by the Broker. State information is updated between the Clients and the Broker. The CoAP PubSub Broker performs a store-and-forward function of state updates between certain CoAP PubSub Clients. Clients Subscribe to state updates which are Published by other Clients, and which are forwarded by the Broker to the subscribing clients. The CoAP PubSub Broker also acts as a REST proxy, retaining the last state update provided by clients to supply in response to Read requests from Clients.

</t>

        <t>
        <figure title="CoAP-PubSub Architecture" anchor="arch-fig">
          <artwork>
            <![CDATA[

      Clients        PubSub         Broker
      +------+         |
      | CoAP |         |
      |PubSub|---------|------+
      |Client|         |      |    +------+
      +------+         |      +----| CoAP |
                       |           |PubSub|
      +------+         |      +----|Broker|
      | CoAP |         |      |    +------+
      |PubSub|---------|------+
      |Client|         |
      +------+         |

]]>
</artwork>
</figure>
</t>
</section>

<section title="CoAP PubSub Broker">
<t>A CoAP PubSub Broker is a CoAP Server that exposes an interface for clients to use to initiate publish-subscribe interactions. Unlike clients, the broker needs to be reachable by all clients. The broker also needs to have sufficient resources (storage, bandwidth, etc.) to host CoAP resources, and potentially buffer messages, on behalf of the clients.
</t>

</section>

<section title="CoAP PubSub Client">
<t>A CoAP PubSub Client interacts with a CoAP PubSub Broker using the CoAP PubSub interface. Clients initiate all interactions with the CoAP-PubSub broker. A data source (e.g., sensor clients) can publish state updates to the broker and data sinks (e.g., actuator clients) can read from or subscribe to state updates from the broker. Application clients can make use of both publish and subscribe in order to exchange state updates with data sources and sinks.</t>

</section> 


<section title="CoAP PubSub Topic">
<t>The clients and broker use topics to identify a particular resource or object in a publish-subscribe system. Topics are conventionally 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 all the clients using the broker share the same namespace for topics.</t>

</section>

</section>

<!-- ====================================================================== -->

<section anchor="function-set" title="CoAP PubSub Function Set">

<t>This section defines the interfaces between a CoAP PubSub Broker and PubSub Clients, which is called the CoAP PubSub Function Set. The examples throughout this section assume the use of CoAP <xref target="RFC7252"/>. A CoAP PubSub Broker implementing this specification MUST support the DISCOVER, CREATE, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE operations defined in this section. With the exception of PUBLISH, all operations in the CoAP PubSub Function Set MUST use confirmable (CON) CoAP messages.
</t>

<section title="DISCOVER">
<t> CoAP PubSub Clients discover CoAP PubSub Brokers by using CoAP Simple Discovery or through a Resource Directory (RD) <xref target="I-D.ietf-core-resource-directory"/>. A CoAP PubSub Broker SHOULD indicate its presence and availability on a network by exposing a link to its PubSub function set at its .well-known/core location. A CoAP PubSub broker MAY register its PubSub function set location with a Resource Directory. <xref target="discover-fig"/> shows an example of a client discovering a local PubSub Function Set using CoAP Simple Discovery. A broker wishing to advertise the CoAP PubSub Function Set for Simple Discovery or through a Resource Directory MUST use the link relation rt="core.ps".
</t>

<t>The DISCOVER interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">GET</t>
<t hangText="URI Template:">/.well-known/core{?rt}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="rt := ">Resource Type (optional). MAY contain the value "core.ps"</t>
</list>
</t>
<t hangText="Content-Format:">application/link-format (if any)</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.05 "Content" with an
application/link-format payload containing one or more matching entries for the broker resource. A PubSub broker SHOULD use the value "ps" for the link subject variable whenever possible.</t>
<t hangText="Failure:"> 4.04 "Not Found" is returned in case no matching entry is found for a unicast request.</t>
<t hangText="Failure:"> 4.00 "Bad Request" is returned in case of a malformed request for a unicast request.</t>
<t hangText="Failure:"> No error response to a multicast request.</t>
</list>
</t>

        <t>
        <figure title="Example of DISCOVER" anchor="discover-fig" align="center">
          <artwork>
            <![CDATA[
Client                                          Broker
  |                                               |
  | ------ GET /.well-known/core?rt=core.ps ----->|
  |                                               |
  | <------2.05 Content “</ps>;rt=core.ps”--------|
  |                                               |
]]>
</artwork>
</figure>
</t>
</section>


<section title="CREATE">
<t>Clients create topics on the broker using the CREATE interface. A client wishing to create a topic MUST use CoAP POST to the PubSub function set location with a payload indicating the desired topic. The topic MUST use the CoRE link format <xref target="RFC6690"/>. The client MAY indicate the lifetime of the topic by including the max-age option in the CREATE request. Broker MUST return a response code of "2.01 Created" if the topic is created. The broker MUST return the appropriate 4.xx response 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 exceeded without any publishes to the topic.
</t>

<t>The CREATE interface is specified as follows:
<list style="hanging">
  <t hangText="Interaction:">Client -> Broker</t>
  <t hangText="Method:">POST</t>
  <t hangText="URI Template:">/{+ps}</t>
  <t hangText="URI Template Variables:">
    <list style="hanging">
      <t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery. A PubSub broker SHOULD use the value "ps" for this variable whenever possible.</t>
    </list>
  </t>
  <t hangText="Content-Format:">application/link-format</t>
  <t hangText="Payload:">The desired topic to CREATE</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.01 "Created". Successful Creation of the topic</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.03 "Forbidden". Topic already exists.</t>
</list>
</t>

<t><xref target="create-fig"/> shows an example of a topic called "topic1" being successfully created.
</t>

<t>
<figure title="Example of CREATE" anchor="create-fig" align="center">
<artwork>
<![CDATA[
Client                                          Broker
  |                                               |
  | -------------- POST /ps "<topic1>" ---------->|
  |                                               |
  | <---------------- 2.01 Created ---------------|
  |                                               |
]]>
</artwork>
</figure>
</t>

</section>


<section title="PUBLISH">
<t>A CoAP PubSub Client uses the PUBLISH interface for updating resources. The client MUST use the PUT method to publish state updates to the CoAP PubSub Broker. A CoAP client publishing on a topic MAY indicate the maximum lifetime of the value by including the max-age option in the publish request. A client MAY use confirmable (CON) or non-confirmable (NON) messages to publish updates to a broker. The broker MUST return a response code of "2.04 Changed" if the publish is accepted or "4.04 Not Found" if the topic does not exist. 
</t>

<t>The Broker MUST publish updates to all clients subscribed on a particular topic each time it receives a publish on that topic. If a client publishes to a broker using non-confirmable messages, the broker MAY publish those messages to subscribed clients using non-confirmable messages. If a client publishes to a broker using confirmable messages, the broker MUST also publish those messages to subscribed clients using confirmable messages. If a client publishes to a broker with the max-age option, the broker MUST publish to subscribed clients including the same value for the max-age option. If a client publishes to a particular topic on a broker with a payload encoded in a particular CoAP Content-Format, the broker MUST publish to subscribed clients on that topic using the same CoAP Content-Format. A broker MUST use CoAP Notification as described in <xref target="I-D.ietf-core-observe"/> to publish to subscribed clients.
</t>

<t>The PUBLISH interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">PUT</t>
<t hangText="URI Template:">/{+ps}/{topic}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery.</t>
<t hangText="topic := ">The desired topic to publish on.</t>
</list>
</t>
<t hangText="Content-Format:">Any valid CoAP Content Format</t>
<t hangText="Payload:">Representation of the topic value (CoAP resource state representation) in the indicated Content-Format</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.04 "Changed". Successful publish, topic is updated</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.04 "Not Found". Topic does not exist.</t>
</list>
</t>

<t><xref target="publish-fig"/> shows an example of a new value being successfully published to the topic "topic1". See <xref target="subscribe-fig"/> for an example of a broker forwarding a message from a publishing client to a subscribed client.
</t>

<t>
<figure title="Example of PUBLISH" anchor="publish-fig" align="center">
<artwork>
<![CDATA[
Client                                          Broker
  |                                               |
  | ---------- PUT /ps/topic1 "1033.3"  --------> |
  |                                               |
  |                                               |
  | <--------------- 2.04 Changed---------------- |
  |                                               |
]]>
</artwork>
</figure>
</t>
</section>


<section title="SUBSCRIBE">
<t>CoAP PubSub Clients subscribe to topics on the Broker using CoAP Observe as described in <xref target="I-D.ietf-core-observe"/>. A CoAP PubSub Client wishing to 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. 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. If the topic was published with the max-age option, the broker MUST set the max-age option in the valid response to the amount of time remaining for the topic to be valid since the last publish. The Broker MUST return a response code of "2.04 No Content" if the max-age of the previously stored value has expired. The Broker MUST return a response code "4.04 Not Found" if the topic does not exist or has been removed.
</t>

<t>The SUBSCRIBE interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">GET</t>
<t hangText="Options:">Observe:0</t>
<t hangText="URI Template:">/{+ps}/{topic}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery.</t>
<t hangText="topic := ">The desired topic to subscribe to.</t>
</list>
</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.05 "Content". Successful subscribe, current value included</t>
<t hangText="Success:"> 2.04 "No Content". Successful subscribe, value not included</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.04 "Not Found". Topic does not exist.</t>
</list>
</t>

<t><xref target="subscribe-fig"/> shows an example of Client2 subscribing to "topic1" and receiving two publish responses from the broker. The first publish from the broker uses the last stored value associated with the topic1. The second publish from the broker is in response to the publish received from  Client1.
</t>

<t>
<figure title="Example of SUBSCRIBE" anchor="subscribe-fig" align="center">
<artwork>
<![CDATA[
Client1   Client2                                          Broker
  |          |                                               |
  |          | ----- GET /ps/topic1 Observe:0 Token:XX ----> |
  |          |                                               |
  |          | <---------- 2.05 Content Observe:10---------- |
  |          |                                               |
  |          |                                               |
  |          |                                               |
  | ---------|----------- PUT /ps/topic1 "1033.3"  --------> |
  |          |                                               |
  |          | <---------- 2.05 Content Observe:11---------- |
  |          |                                               |
]]>
</artwork>
</figure>
</t>
</section>


<section title="UNSUBSCRIBE">
<t>CoAP PubSub Clients unsubscribe from topics on the Broker using the CoAP Cancel Observation operation. A CoAP PubSub Client wishing to unsubscribe to a topic on a Broker MUST either use CoAP GET with Observe using an Observe parameter of 1 or send a CoAP Reset message in response to a publish <xref target="I-D.ietf-core-observe"/>.
</t>

<t>The UNSUBSCRIBE interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">GET</t>
<t hangText="Options:">Observe:1</t>
<t hangText="URI Template:">/{+ps}/{topic}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery.</t>
<t hangText="topic := ">The desired topic to unsubscribe from.</t>
</list>
</t>

</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.05 "Content". Successful unsubscribe, current value included</t>
<t hangText="Success:"> 2.04 "No Content". Successful unsubscribe, value not included</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.04 "Not Found". Topic does not exist.</t>
</list>
</t>

<t><xref target="unsubscribe-fig"/> shows an example of a client unsubscribe using the Observe=1 cancellation method.
</t>

<t>
<figure title="Example of UNSUBSCRIBE" anchor="unsubscribe-fig" align="center">
<artwork>
<![CDATA[
Client                                          Broker
  |                                               |
  | ----- GET /ps/topic1 Observe:1 Token:XX ----> |
  |                                               |
  | <------------- 2.05 Content ----------------- |
  |                                               |
]]>
</artwork>
</figure>
</t>
</section>


<section title="READ">
<t>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 uses the CoAP GET method. 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. If the topic was published with the max-age option, the broker MUST set the max-age option in the valid response to the amount of time remaining for the topic to be valid since the last publish. The Broker MUST return a response code of "2.04 No Content" if the max-age of the previously stored value has expired. The Broker MUST return a response code "4.04 Not Found" if the topic does not exist or has been removed.
</t>

<t>The READ interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">GET</t>
<t hangText="URI Template:">/{+ps}/{topic}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery.</t>
<t hangText="topic := ">The desired topic to READ.</t>
</list>
</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.05 "Content". Successful READ, current value included</t>
<t hangText="Success:"> 2.04 "No Content". Topic exists, value not included</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.04 "Not Found". Topic does not exist.</t>
</list>
</t>

<t><xref target="read-fig"/> shows an example of s successful READ from topic1.
</t>

<t>
<figure title="Example of READ" anchor="read-fig" align="center">
<artwork>
<![CDATA[
Client                                          Broker
  |                                               |
  | -------------- GET /ps/topic1  -------------> |
  |                                               |
  |                                               |
  | <--------------- 2.05 Content --------------- |
  |                                               |
]]>
</artwork>
</figure>
</t>

</section>


<section title="REMOVE">
<t> A CoAP PubSub Client wishing to remove a topic can use the CoAP Delete operation on the URI of the topic. The CoAP PubSub Broker MUST return "2.02 Deleted" if the remove operation is successful. The broker MUST return the appropriate 4.xx response code indicating the reason for failure if the topic can not be removed.
</t>

<t>The REMOVE interface is specified as follows:
<list style="hanging">
<t hangText="Interaction:">Client -> Broker</t>
<t hangText="Method:">DELETE</t>
<t hangText="URI Template:">/{+ps}/{topic}</t>
<t hangText="URI Template Variables:">
<list style="hanging">
<t hangText="ps := ">PubSub Function Set path (mandatory). The path of the PubSub Function Set, as obtained from discovery.</t>
<t hangText="topic := ">The desired topic to REMOVE.</t>
</list>
</t>
<t hangText="Content-Format:">None</t>
<t hangText="Response Payload:">None</t>
</list>
</t>

<t>The following response codes are defined for this interface:
<list style="hanging">
<t hangText="Success:"> 2.02 "Deleted". Successful remove</t>
<t hangText="Failure:"> 4.00 "Bad Request". Malformed request.</t>
<t hangText="Failure:"> 4.01 "Unauthorized". Authorization failure.</t>
<t hangText="Failure:"> 4.04 "Not Found". Topic does not exist.</t>
</list>
</t>

<t><xref target="subscribe-fig"/> shows a successful remove of topic1.
</t>

<t>
<figure title="Example of REMOVE" anchor="remove-fig" align="center">
<artwork>
<![CDATA[
Client                                         Broker
 |                                               |
 | ------------- DELETE /ps/topic1 ------------> |
 |                                               |
 |                                               |
 | <-------------- 2.02 Deleted ---------------- |
 |                                               |
]]>
</artwork>
</figure>
</t>

</section>

</section>

<!-- ====================================================================== -->

<section title="CoAP PubSub Operation with Resource Directory">
<t>A CoAP PubSub Broker may register a PubSub Function Set with a Resource Directory. A PubSub Client may use an RD to discover a PubSub Broker.
</t>

<t>A CoAP PubSub Client may register CoRE Links <xref target="RFC6690"/> to created PubSub Topics with an RD. A PubSub Client may use an RD to discover PubSub Topics. A client which registers PubSub Topics with an RD MUST use the context relation (con) <xref target="I-D.ietf-core-resource-directory"/> to indicate that the context of the registered links is the PubSub Broker.
</t>

</section>


<!-- ====================================================================== -->

<section title="Sleep-Wake Operation">

<t>CoAP PubSub provides a way for client nodes to sleep between operations, conserving energy during idle periods. This is made possible by shifting the server role to the broker, allowing the broker to be always-on and respond to requests from other clients while a particular client is sleeping.</t>

<t>For example, the broker will retain the last state update received from a sleeping client, in order to supply the most recent state update to other clients in response to read and subscribe operations.</t>

<t>Likewise, the broker will retain the last state update recieved on the topic such that a sleeping client, upon waking, can perform a read operation to the broker to update its own state from the most recent system state update.</t>

</section>

 
<!-- ====================================================================== -->

<section anchor="SecurityConsiderations" title="Security Considerations">
<t>CoAP-PubSub re-uses CoAP <xref target="RFC7252"/>, CoRE Resource Directory <xref target="I-D.ietf-core-resource-directory"/>, and Web Linking <xref target="RFC5988"/> and therefore the security considerations of those documents also apply to this specification. Additionally, a CoAP-PubSub broker and the clients SHOULD authenticate each other and enforce access control policies. A malicious client could subscribe to data it is not authorized to or mount a denial of service attack against the broker by publishing a large number of resources. The authentication can be performed using the already standardized DTLS offered mechanisms, such as certificates. DTLS also allows communication security to be established to ensure integrity and confidentiality protection of the data exchanged between these relevant parties. Provisioning the necessary credentials, trust anchors and authorization policies is non-trivial and subject of ongoing work.</t>

<t>The use of a CoAP-PubSub broker introduces challenges for the use of end-to-end security between for example a client device on a sensor network and a client application running in a cloud-based server infrastructure since brokers terminate the exchange. While running separate DTLS sessions from the client device to the broker and from broker to client application protects confidentially on those paths, the client device does not know whether the commands coming from the broker are actually coming from the client application. Similarly, a client application requesting data does not know whether the data originated on the client device. For scenarios where end-to-end security is desirable the use of application layer security is unavoidable. Application layer security would then provide a guarantee to the client device that any request originated at the client application. Similarly, integrity protected sensor data from a client device will also provide guarantee to the client application that the data originated on the client device itself. The protected data can also be verified by the intermediate broker ensuring that it stores/caches correct request/response and no malicious messages/requests are accepted. The broker would still be able to perform aggregation of data/requests collected.</t>

<t>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 RECOMMENDED <xref target="I-D.selander-ace-object-security"/>.</t>
</section> 


<!-- ====================================================================== -->
<!-- 
<section anchor="PrivacyConsiderations" title="Privacy Considerations">
  <t>TBD</t>
</section>
--> 
<!-- ====================================================================== -->

<section anchor="iana" title="IANA Considerations">
<t>This document registers one attribute value in the Resource Type (rt=) registry established with <xref target="RFC6690"/> and appends to the definition of one CoAP Response Code in the CoRE Parameters Registry.</t>

<section title="Resource Type value 'core.ps'">
<t>
<list style="symbols">
<t>Attribute Value: core.ps</t>
<t>Description: <xref target="function-set"/> of [[This document]]</t>
<t>Reference: [[This document]]</t>
<t>Notes: None</t>
</list>
</t>
</section>

<section title="Response Code value '2.04'">
<t>
<list style="symbols">
<t>Response Code: 2.04</t>
<t>Description: Add No Content response to GET to the existing definition of the 2.04 response code.</t>
<t>Reference: [[This document]]</t>
<t>Notes: None</t>
</list>
</t>
</section>

</section>

<!-- ====================================================================== -->

    
<section anchor="acks" title="Acknowledgements">
  <t>The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit Sethi, Peter Van der Stok, Tim Kellogg, Anders Eriksson, and Goran Selander for their contributions and reviews. </t>
</section>


</middle>

<!-- ====================================================================== -->
  <back>

<references title="Normative References">
<?rfc include="reference.RFC.3986"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6690"?>
<?rfc include="reference.RFC.6570"?>
<?rfc include="reference.I-D.ietf-core-resource-directory"?>
<?rfc include="reference.I-D.ietf-core-observe"?>
<?rfc include="reference.I-D.selander-ace-object-security"?>
<!--      <?rfc include="reference.I-D.draft-ietf-core-interfaces"?> -->
<?rfc include="reference.RFC.7252"?>


    </references>

    <references title="Informative References">
	      <?rfc include="reference.RFC.5988"?>
    </references>
  
  </back>

</rfc>