Network Working Group                                          M. Koster
Internet-Draft                                               ARM Limited
Intended status: Standards Track                              A. Keranen
Expires: January 5, 2015                                      J. Jimenez
                                                                Ericsson
                                                            July 4, 2014


    Message Queueing in the Constrained Application Protocol (CoAP)
                    draft-koster-core-coapmq-00.txt

Abstract

   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 publish-
   subscribe message queuing functionality for CoAP that extends the
   capabilities for supporting nodes with long breaks in connectivity
   and/or up-time.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Koster, et al.           Expires January 5, 2015                [Page 1]


Internet-Draft          Message Queueing in CoAP               July 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  RD Server with associated CoAP-MQ Broker  . . . . . . . .   4
     3.2.  Client Endpoint . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Server Endpoint . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Publish-Subscribe Topics  . . . . . . . . . . . . . . . .   5
   4.  CoAP-MQ Registration and discovery  . . . . . . . . . . . . .   6
     4.1.  Register PubSub Endpoint  . . . . . . . . . . . . . . . .   6
     4.2.  Unregister Endpoint . . . . . . . . . . . . . . . . . . .   7
   5.  CoAP-MQ Functions and Interactions  . . . . . . . . . . . . .   7
     5.1.  Client Role Endpoint Functions  . . . . . . . . . . . . .   8
       5.1.1.  Client Endpoint PUBLISH to CoAP-MQ broker . . . . . .   8
       5.1.2.  Client Endpoint SUBSCRIBE, Broker PUBLISH . . . . . .   8
       5.1.3.  Client Endpoint GET from CoAP-MQ Broker . . . . . . .   9
     5.2.  Server Role Endpoint Functions  . . . . . . . . . . . . .   9
       5.2.1.  CoAP-MQ broker SUBSCRIBES to Server Role EP . . . . .  10
       5.2.2.  CoAP-MQ Broker Publishes to Server Role Endpoint  . .  10
       5.2.3.  CoAP-MQ Broker GET from Server Role Endpoint  . . . .  11
   6.  Enabling Multiple Publishers  . . . . . . . . . . . . . . . .  11
     6.1.  Creating a Topic  . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Publishing a Topic from Multiple Publishers . . . . . . .  12
     6.3.  Subscribing to a topic with multiple publishers . . . . .  12
   7.  Sleep-Wakeup Operation and Message Queueing . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Resource Type value 'core.pubsub.client'  . . . . . . . .  14
     9.2.  Resource Type value 'core.pubsub.server'  . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Constrained Application Protocol (CoAP) [6] supports machine to
   machine communication across networks of constrained devices.  One
   important class of constrained devices includes devices that are
   intended to run for years from a small battery, or by scavenging




Koster, et al.           Expires January 5, 2015                [Page 2]


Internet-Draft          Message Queueing in CoAP               July 2014


   energy from their environment.  These devices 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
   devices must communicate using a client role, whereby the endpoint is
   responsible for initiating communication.

   This document specifies the means for nodes with limited reachability
   to communicate using simple extensions to CoAP and the CoRE Resource
   Directory [4].  The extensions enable publish-subscribe communication
   using a Message Queue (MQ) broker node that enables store-and-forward
   messaging between two or more nodes.

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

2.  Terminology

   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 [1].

   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in [8] and [2].  Readers should also
   be familiar with the terms and concepts discussed in [6] and [4].
   The URI template format, see [3], is used to describe the REST
   interfaces defined in this specification.

   The following entities are used in this specification:

   CoAP Message Queue (CoAP-MQ) Service  A service provided by a node or
      system where CoAP messages sent by one endpoint to another are
      queued (stored) by intermediate node(s) and forwarded only when
      suitable, e.g., when the message recipient endpoint is not
      sleeping.

   CoAP-MQ Broker  A server node capable of storing messages to and from
      other nodes and able to match subscriptions and publications in
      order to route messages to right destinations.

   CoAP-MQ Endpoint  An endpoint that implements the MQ function set
      defined in Section 5.  A CoAP-MQ endpoint has two potential roles,
      CoAP-MQ client and CoAP-MQ server

   This specification makes use of the following additional terminology:




Koster, et al.           Expires January 5, 2015                [Page 3]


Internet-Draft          Message Queueing in CoAP               July 2014


   CoAP Message Queue (CoAP-MQ) Service  A service provided by a node or
      system where CoAP messages sent by one endpoint to another are
      queued (stored) by intermediate node(s) and forwarded only when
      suitable, e.g., when the message recipient endpoint is not
      sleeping.

   CoAP-MQ Broker  A server node capable of storing messages to and from
      other nodes and able to match subscriptions and publications in
      order to route messages to right destinations.

   CoAP-MQ function set  A group of well-known REST resources that
      together provide the CoAP-MQ service.

   CoAP-MQ Endpoint  An endpoint that implements the CoAP-MQ function
      set.  A CoAP-MQ endpoint has two potential roles, CoAP-MQ client
      and CoAP-MQ server.

   Publish-Subscribe (pub-sub)  A messaging paradigm where messages are
      published (e.g., to a broker) and potential receivers can
      subscribe to receive the messages.

   Topic  In Publish-Subscribe systems a topic is a unique identifying
      string for a particular item or object being published and/or
      subscribed to.

3.  Architecture

3.1.  RD Server with associated CoAP-MQ Broker

   Figure 1 shows an example architecture of a CoAP-MQ capable service.
   A Resource Directory service accepts registrations and registration
   updates from one or more endpoints and hosts a resource discovery
   service for one or more web application clients.  State information
   is updated from the endpoints to the CoAP-MQ broker.  Web clients
   subscribe to the state of the endpoint from the CoAP-MQ broker, and
   publish updates to the endpoint state through the CoAP-MQ broker.
   The CoAP-MQ broker performs a store-and-forward function between web
   clients and the CoAP-MQ capable endpoints.  The CoAP-MQ broker is
   also responsible for acting as a proxy, returning the last published
   value to web clients or other endpoints on behalf endpoints that are
   sleeping.










Koster, et al.           Expires January 5, 2015                [Page 4]


Internet-Draft          Message Queueing in CoAP               July 2014


    Endpoints                  Service                   Applications
                              +------+
                              |      |
               +- register -> |  RD  | <- discover -+
    +------+   |              |      |              |   +--------+
    |      | --+              +------+              +-- |  Web   |
    |  EP  |                                            | Client |
    |      | <-+              +------+              +-> |  app   |
    +------+   |              | CoAP |              |   +--------+
     |  EP  |  +-- pub/sub -> |  MQ  | <- pub/sub --+    |  app   |
     +------+                 |Broker|                   +--------+
                              +------+


                      Figure 1: CoAP MQ Architecture

3.2.  Client Endpoint

   Client endpoints initiate all interactions with the RD and MQ broker.
   If the endpoint is an actuator it will need to either use CoAP
   Observe [I-D.ietf-core-observe] or periodically poll the MQ broker to
   check for updates.  A CoAP-MQ client endpoint MUST use CoAP PUT
   operations to update its state on the MQ broker.  An endpoint SHOULD
   update the RD periodically to indicate that it is still alive even if
   it has no pending data updates.  Endpoints can operate in the client
   role even if not directly reachable from the CoAP-MQ broker or RD
   server.

3.3.  Server Endpoint

   Server endpoint interactions require the CoAP-MQ broker to perform
   the client role, initiating interaction with the server endpoint.
   The CoAP-MQ broker MAY then use PUT operations to update state at the
   server endpoint, and MAY use GET or GET+Observe to subscribe to
   resources at the endpoint.  Server mode endpoints are required to be
   reachable from the CoAP-MQ broker.  In a network containing both
   client and server endpoints, client endpoints MAY subscribe to server
   endpoints directly, in broker-less configurations, using RD or core-
   link-format metadata in .well-known/core to discover the CoAP-MQ
   capabilities and using GET+Observe to subscribe to the desired
   topics.

3.4.  Publish-Subscribe Topics

   Topic are strings used to identify particular resources and objects
   in publish-subscribe systems.  Topics are conventionally formed as a
   hierarchy, e.g. "/sensors/weather/barometer/pressure".




Koster, et al.           Expires January 5, 2015                [Page 5]


Internet-Draft          Message Queueing in CoAP               July 2014


   Implementations are free to map topics to resources, reusing existing
   resource addressing schemes.

4.  CoAP-MQ Registration and discovery

   An endpoint wishing to use a CoAP-MQ broker registers with an RD
   server that advertises a service having the the "core.mq" attribute.
   This indicates that there is a CoAP-MQ broker at the location
   returned by the discovery query as shown in Figure 2.  The endpoint
   registers topics using the "rt=core.pubsub.client" or
   "core.pubsub.server" (or both) attributes to indicate intention to
   use CoAP-MQ and which roles are supported.

   A server that implements a CoAP_MQ broker MAY advertize this
   capability by registering the rt="core.mq" with an associated
   Resource Directory.  If a server advertizes as a CoAP-MQ Broker, it
   MUST support the transactions described in section 5 of this
   document.  As server that implements the CoAP-MQ Broker MAY also
   implement sleeping endpoint and message queueing support referred to
   in Section 6 of this document.

4.1.  Register PubSub Endpoint

   Figure 2 shows the flow of the registration operation.  Discovery
   proceeds as per CoRE Resource Directory[I-D.ietf-core-resource-
   directory-01].  When an endpoint wishes to use CoAP-MQ, it discovers
   the rt="core.mq" attribute at the RD service associated with the
   CoAP-MQ broker and registers its CoAP-MQ resources with the RD server
   by registering topics having the rt="core.pubsub" attribute.  Topics
   are created using an initial POST operation to the registered topic
   or any valid sub-topic.  For example, if the registered topic is
   "/sensors/weather", the sub-topic "/sensors/weather/barometer" is
   created using a POST to "/mq/sensors/weather/barometer".  An
   implementation MAY mix CoAP-MQ resources and CoAP REST resources on
   the same endpoint.  Endpoint registration proceeds as per normal RD
   registration.















Koster, et al.           Expires January 5, 2015                [Page 6]


Internet-Draft          Message Queueing in CoAP               July 2014


   EP                                               MQ        RD
    |                  MQ DISCOVERY                 |         |
    | -------- GET /.well-known/core?rt=core.mq --- | ------> |
    |                                               |         |
    | <-------- 2.05 Content "</mq>; rt=core.mq"--- | ------- |
    |                                               |         |
    |                                               |         |
    |                TOPIC REGISTRATION             |         |
    | ---POST /rd "</mq/0/xx>;rt=core.pubsub.xx"--- | ------> |
    |                                               |         |
    | <-------- 2.01 Created Location: /rd/1234 --- | ------- |
    |                                               |         |
    |                                               |         |
    |                 FIRST PUBLISH                 |         |
    | ---------------- POST /mq/0/... ------------> |         |
    |                                               |         |
    | <--------------- 2.01 Created---------------- |         |
    |                                               |         |


                   Figure 2: Discovery and Registration

4.2.  Unregister Endpoint

   CoaAP-MQ endpoints indicate the end of their registration tenure by
   either explicitly unregistering, as in Figure 3, or allowing the
   lifetime of the previous registration to expire.


   EP                                               MQ        RD
   |                                               |         |
   |                    UNREGISTER                 |         |
   | ---------------- DELETE /rd/1234 ------------ | ------> |
   |                                               |         |
   | <-------- 2.02 Deleted Location: /rd/1234 --- | ------- |
   |                                               |         |
   |                                               |         |


                       Figure 3: Unregister Endpoint

5.  CoAP-MQ Functions and Interactions

   This section describes the transaction flows and interactions between
   CoAP-MQ endpoints and CoAP-MQ brokers.  Client endpoint functions are
   used by endpoints implementing the client role, for example to enable
   sleep/wakeup and partial connectivity.  Server role endpoint
   functions are used by enpoints implementing the server role, for



Koster, et al.           Expires January 5, 2015                [Page 7]


Internet-Draft          Message Queueing in CoAP               July 2014


   example always on, reachable, endpoints.  An endpoint implementation
   MAY support both client role and server role at an endpoint.  A CoAP-
   MQ broker MUST implement support for both client role and server role
   endpoints.

5.1.  Client Role Endpoint Functions

   This section describes the transaction flows and interactions between
   CoAP-MQ endpoints and CoAP-MQ brokers where the endpoint supports the
   client role.  A client registering the "core.pubsub.client" attribute
   MUST support the client role endpoint functions and interactions
   described in this section.

5.1.1.  Client Endpoint PUBLISH to CoAP-MQ broker

   Client endpoint PUBLISH updates to CoAP-MQ broker.


   EP                                              MQ        RD
   |                                               |         |
   |                                               |         |
   |                    PUBLISH                    |         |
   | --------------- PUT /mq/0/... --------------> |         |
   |                                               |         |
   |                                               |         |
   | <--------------- 2.04 Changed---------------- |         |
   |                                               |         |
   |                                               |         |


              Figure 4: Client Role PUBLISH from EP to Broker

5.1.2.  Client Endpoint SUBSCRIBE, Broker PUBLISH

   Client mode endpoint subscribes to the topic at the CoAP-MQ broker
   using GET+Observe.  Published updates to the CoAP-MQ broker are
   published to the Endpoint using Observe response tokens.  Client
   endpoint MAY update actuator or resource based on received values
   associated with responses.  A CoAP-MQ broker MUST publish updates to
   subscribed endpoints upon receiving published updates on the
   associated topics.










Koster, et al.           Expires January 5, 2015                [Page 8]


Internet-Draft          Message Queueing in CoAP               July 2014


   EP                                              MQ        RD
   |                                               |         |
   |                                               |         |
   |                 SUBSCRIBE                     |         |
   | ----- GET /mq/0/... Observe: Token:XX ------> |         |
   |                                               |         |
   |                  PUBLISH                      |         |
   | <---------- 2.05 Content Observe:10---------- |         |
   |                                               |         |
   |                  PUBLISH                      |         |
   | <---------- 2.05 Content Observe:12---------- |         |
   |                                               |         |
   |                  PUBLISH                      |         |
   | <---------- 2.05 Content Observe:15---------- |         |
   |                                               |         |
   |                                               |         |


   Figure 5: Client Role Endpoint SUBSCRIBE, Broker PUBLISH to Endpoint

5.1.3.  Client Endpoint GET from CoAP-MQ Broker

   Client mode endpoint MAY issue GET to topic without Observe as needed
   to obtain last published state from the CoAP-MQ broker.


   EP                                              MQ        RD
   |                                               |         |
   |                                               |         |
   |                                               |         |
   | --------------- GET /mq/0/... --------------> |         |
   |                                               |         |
   |                                               |         |
   | <--------------- 2.05 Content --------------- |         |
   |                                               |         |
   |                                               |         |


                Figure 6: Client EP GET from CoAP-MQ Broker

5.2.  Server Role Endpoint Functions

   This section describes the transaction flows and interactions between
   CoAP-MQ endpoints and CoAP-MQ brokers where the endpoint supports the
   server role.  An endpoint registering the "core.pubsub.server"
   attribute MUST support these functions and interactions.





Koster, et al.           Expires January 5, 2015                [Page 9]


Internet-Draft          Message Queueing in CoAP               July 2014


5.2.1.  CoAP-MQ broker SUBSCRIBES to Server Role EP

   The server mode endpoint requires the CoAP-MQ broker to act as a
   client and subscribe to a resource on the endpoint using GET +
   Observe.  A CoAP-MQ broker MAY subscribe to topics registered by a
   server role endpoint at any time.  A CoAP-MQ broker MUST subscribe to
   a topic registered by a server role endpoint upon receiving a
   subscription on the associated topic.  A CoAP-MQ broker MUST forward
   state updates received from a publishing endpoint to all endpoints
   subscribed on the associated topic.Figure 7 shows the flow of a CoAP-
   MQ Broker subscribing to a server role endpoint.


   EP                                               MQ        RD
    |                                               |         |
    |                                               |         |
    |                SUBSCRIBE                      |         |
    | <------ GET /0/... Observe: Token:XX -------- |         |
    |                                               |         |
    |                 PUBLISH                       |         |
    | ---------- 2.05 Content Observe:10----------> |         |
    |                                               |         |
    |                 PUBLISH                       |         |
    | ---------- 2.05 Content Observe:12----------> |         |
    |                                               |         |
    |                 PUBLISH                       |         |
    | ---------- 2.05 Content Observe:15----------> |         |
    |                                               |         |
    |                                               |         |


               Figure 7: Broker SUBSCRIBE to Server Role EP

5.2.2.  CoAP-MQ Broker Publishes to Server Role Endpoint

   CoAP-MQ broker MUST update server mode endpoint using PUT when upon
   receiving updates published on the associated topics.  Endpoint
   server MAY update actuator or resource upon receiving published state
   updates from the broker.












Koster, et al.           Expires January 5, 2015               [Page 10]


Internet-Draft          Message Queueing in CoAP               July 2014


   EP                                               MQ        RD
    |                                               |         |
    |                                               |         |
    |                    PUBLISH                    |         |
    | <--------------- PUT /0/... ----------------- |         |
    |                                               |         |
    |                                               |         |
    | ---------------- 2.04 Changed---------------> |         |
    |                                               |         |
    |                                               |         |


                Figure 8: Broker PUBLISH to Server Role EP

5.2.3.  CoAP-MQ Broker GET from Server Role Endpoint

   CoAP-MQ broker MAY issue GET without Observe as needed to obtain
   state update from the server role endpoint.


   EP                                               MQ        RD
    |                                               |         |
    |                                               |         |
    |                                               |         |
    | <---------------- GET /0/... ---------------- |         |
    |                                               |         |
    |                                               |         |
    | ---------------- 2.05 Content --------------> |         |
    |                                               |         |
    |                                               |         |


              Figure 9: Broker GET from Server Role Endpoint

6.  Enabling Multiple Publishers

6.1.  Creating a Topic

   After registration of the EP in the RD and discovering the CoAP-MQ
   function, a designated EP acting as publisher for a particular topic
   is responsible for creating such topic.  To do so, it will have to
   register the new topic in the RD and create it on the MQ function by
   doing a first publication as shown in Figure 2.

   After the topic has been created in the CoAP-MQ broker, the broker
   will be responsible of hosting this resource and to queue messages
   published on it as explained in Section 5




Koster, et al.           Expires January 5, 2015               [Page 11]


Internet-Draft          Message Queueing in CoAP               July 2014


6.2.  Publishing a Topic from Multiple Publishers

   After the topic has been registered in the RD and is created in the
   CoAP-MQ broker, any device with the right access permissions can
   publish on that topic by using the topic field.  For example in the
   following diagram, both EP1 and EP2 update the same topic that EP3
   has previously subscribed to.

   After the topic has been created in the CoAP-MQ Broker, the broker
   will be responsible of hosting this resource and to queue messages
   published on it as explained in Section 5


   EP1     EP2                                     MQ
   |       |            PUBLISH                    |
   | -------------- PUT /mq/0/TOPIC1 ------------> |
   |       |                                       |
   | <--------------- 2.04 Changed---------------- |
   |       |                                       |
   |       |            PUBLISH                    |
   |       | ------ PUT /mq/0/TOPIC1 ------------> |
   |       |                                       |
   |       | <------- 2.04 Changed---------------- |
   |       |                                       |


             Figure 10: Multiple CoAP-MQ EPs PUBLISH to Broker

6.3.  Subscribing to a topic with multiple publishers

   Subscription to this topic is the same as in Section 5, since it acts
   as any other resource.  Following the previous example, if EP3 is
   subscribed to the shared topic, it should receive two updates from
   both EP1 and EP2.

















Koster, et al.           Expires January 5, 2015               [Page 12]


Internet-Draft          Message Queueing in CoAP               July 2014


   EP3                                              MQ
   |                 SUBSCRIBE                     |
   | ------- GET /mq/0/TOPIC1 Observe -----------> |
   |                                               |
   |                  PUBLISH                      |
   | <-----------  2.05 Content EP1 -------------- |
   |                                               |
   |                  PUBLISH                      |
   | <-----------  2.05 Content EP2 -------------- |
   |                                               |


              Figure 11: CoAP-MQ Endpoint SUBSCRIBE to Broker

7.  Sleep-Wakeup Operation and Message Queueing

   A CoAP-MQ broker MAY implement support for sleeping endpoints and
   queueing of messages as provided for in [7]

8.  Security Considerations

   CoAP-MQ re-uses CoAP [6], CoRE Resource Directory [4], and Web
   Linking [8] and therefore the security considerations of those
   documents also apply to this specification.  Additionally, a CoAP-MQ
   broker and the endpoints SHOULD authenticate each other and enforce
   access control policies.  A malicious EP 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.

   The use of a CoAP-MQ broker introduces challenges for the use of end-
   to-end security between the end device and the cloud-based server
   infrastructure since brokers terminate the exchange.  While running
   separate DTLS sessions from the EP to the broker and from broker to
   the web application protects confidentially on those paths, the
   client/server EP does not know whether the commands coming from the
   broker are actually coming from the client web application.
   Similarly, a client web application requesting data does not know
   whether the data originated on the server EP.  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 EP that any request originated at
   the client web application.  Similarly, integrity protected sensor



Koster, et al.           Expires January 5, 2015               [Page 13]


Internet-Draft          Message Queueing in CoAP               July 2014


   data from a server EP will also provide guarantee to the client web
   application that the data originated on the EP 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.

   Depending on the level of trust users and system designers place in
   the CoAP-MQ broker, the use of end-to-end encryption may also be
   envisioned.  The CoAP-MQ broken would then only be able to verify the
   request/response message/commands and store-and-forward without being
   able to inspect the content.  The solution for providing application
   layer security will depend on the utilized data encoding.  For
   example, with a JSON-based data encoding the work from the JOSE
   working group could be re-used.  Distribution of the credentials for
   accomplishing end-to-end security might introduce challenges if
   previously unknown parties need to exchange data.

9.  IANA Considerations

   This document registers two attribute values in the Resource Type
   (rt=) registry established with RFC 6690 [2].

9.1.  Resource Type value 'core.pubsub.client'

   o  Attribute Value: core.pubsub.client

   o  Description: Section X of [[This document]]

   o  Reference: [[This document]]

   o  Notes: None

9.2.  Resource Type value 'core.pubsub.server'

   o  Attribute Value: core.pubsub.server

   o  Description: Section Y of [[This document]]

   o  Reference: [[This document]]

   o  Notes: None

10.  Acknowledgements

   Hannes Tschofenig, Zach Shelby





Koster, et al.           Expires January 5, 2015               [Page 14]


Internet-Draft          Message Queueing in CoAP               July 2014


11.  References

11.1.  Normative References

   [1]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]        Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012.

   [3]        Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570, March 2012.

   [4]        Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
              Directory", draft-ietf-core-resource-directory-01 (work in
              progress), December 2013.

   [5]        Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-14 (work in progress), June 2014.

   [6]        Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [7]        Open Mobile Alliance, "OMA LightweightM2M v1.0",
              http://technical.openmobilealliance.org/Technical/
              technical-information/release-program/current-releases/
              oma-lightweightm2m-v1-0, 12 2013.

11.2.  Informative References

   [8]        Nottingham, M., "Web Linking", RFC 5988, October 2010.

Authors' Addresses

   Michael Koster
   ARM Limited

   Email: Michael.Koster@arm.com


   Ari Keranen
   Ericsson

   Email: ari.keranen@ericsson.com







Koster, et al.           Expires January 5, 2015               [Page 15]


Internet-Draft          Message Queueing in CoAP               July 2014


   Jaime Jimenez
   Ericsson

   Email: jaime.jimenez@ericsson.com















































Koster, et al.           Expires January 5, 2015               [Page 16]