idnits 2.17.1 draft-koster-core-coap-pubsub-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-14 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'OMALightweightM2M' -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Koster 3 Internet-Draft ARM Limited 4 Intended status: Standards Track A. Keranen 5 Expires: April 30, 2015 J. Jimenez 6 Ericsson 7 October 27, 2014 9 Publish-Subscribe in the Constrained Application Protocol (CoAP) 10 draft-koster-core-coap-pubsub-00 12 Abstract 14 The Constrained Application Protocol, CoAP, and related extensions 15 are intended to support machine-to-machine communication in systems 16 where one or more nodes are resource constrained, in particular for 17 low power wireless sensor networks. This document defines publish- 18 subscribe and message queuing functionality for CoAP that extends the 19 capabilities for supporting nodes with long breaks in connectivity 20 and/or up-time. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. RD Server with associated CoAP-PubSub Broker . . . . . . 4 60 3.2. Client Endpoint . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Server Endpoint . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Publish-Subscribe Topics . . . . . . . . . . . . . . . . 5 63 4. CoAP-PubSub Registration and discovery . . . . . . . . . . . 5 64 4.1. Register CoAP-PubSub Endpoint . . . . . . . . . . . . . . 6 65 4.2. Unregister Endpoint . . . . . . . . . . . . . . . . . . . 6 66 5. CoAP-PubSub Functions and Interactions . . . . . . . . . . . 7 67 5.1. Client Role Endpoint Functions . . . . . . . . . . . . . 7 68 5.1.1. Client Endpoint PUBLISH to CoAP-PubSub broker . . . . 7 69 5.1.2. Client Endpoint SUBSCRIBE, Broker PUBLISH . . . . . . 8 70 5.1.3. Client Endpoint GET from CoAP-PubSub Broker . . . . . 9 71 5.2. Server Role Endpoint Functions . . . . . . . . . . . . . 9 72 5.2.1. CoAP-PubSub broker SUBSCRIBES to Server Role EP . . . 9 73 5.2.2. CoAP-PubSub Broker Publishes to Server Role Endpoint 10 74 5.2.3. CoAP-PubSub Broker GET from Server Role Endpoint . . 10 75 6. Enabling Multiple Publishers . . . . . . . . . . . . . . . . 11 76 6.1. Creating a Topic . . . . . . . . . . . . . . . . . . . . 11 77 6.2. Publishing a Topic from Multiple Publishers . . . . . . . 11 78 6.3. Subscribing to a topic with multiple publishers . . . . . 12 79 7. Sleep-Wakeup Operation and Message Queueing . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Resource Type value 'core.pubsub.client' . . . . . . . . 14 83 9.2. Resource Type value 'core.pubsub.server' . . . . . . . . 14 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 11.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 The Constrained Application Protocol (CoAP) [RFC7252] supports 93 machine to machine communication across networks of constrained 94 devices. One important class of constrained devices includes devices 95 that are intended to run for years from a small battery, or by 96 scavenging energy from their environment. These devices spend most 97 of their time in a sleeping state with no network connectivity. 99 Devices may also have limited reachability due to certain middle- 100 boxes, such as Network Address Translators (NATs) or firewalls. Such 101 devices must communicate using a client role, whereby the endpoint is 102 responsible for initiating communication. 104 This document specifies the means for nodes with limited reachability 105 to communicate using simple extensions to CoAP and the CoRE Resource 106 Directory [I-D.ietf-core-resource-directory]. The extensions enable 107 publish-subscribe communication using a broker node that enables 108 store-and-forward messaging between two or more nodes. 110 The mechanisms specified in this document are meant to address key 111 design requirements from earlier CoRE drafts covering sleepy node 112 support and mirror server. 114 2. Terminology 116 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 117 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 118 specification are to be interpreted as described in [RFC2119]. 120 This specification requires readers to be familiar with all the terms 121 and concepts that are discussed in [RFC5988] and [RFC6690]. Readers 122 should also be familiar with the terms and concepts discussed in 123 [RFC7252] and [I-D.ietf-core-resource-directory]. The URI template 124 format, see [RFC6570], is used to describe the REST interfaces 125 defined in this specification. 127 This specification makes use of the following additional terminology: 129 CoAP Publish-Subscribe (CoAP-PubSub) Service: A service provided by 130 a node or system where CoAP messages sent by one endpoint to 131 another are queued (stored) by intermediate node(s) and forwarded 132 only when suitable, e.g., when the message recipient endpoint is 133 not sleeping. 135 CoAP-PubSub Broker: A server node capable of storing messages to and 136 from other nodes and able to match subscriptions and publications 137 in order to route messages to right destinations. 139 CoAP-PubSub function set: A group of well-known REST resources that 140 together provide the CoAP-PubSub service. 142 CoAP-PubSub Endpoint An endpoint that implements the CoAP-PubSub 143 function set. A CoAP-PubSub endpoint has two potential modes, 144 CoAP-PubSub Client and CoAP-PubSub Server. 146 Publish-Subscribe (pub-sub): A messaging paradigm where messages are 147 published (e.g., to a broker) and potential receivers can 148 subscribe to receive the messages. 150 Topic: In Publish-Subscribe systems a topic is a unique identifying 151 string for a particular item or object being published and/or 152 subscribed to. 154 3. Architecture 156 3.1. RD Server with associated CoAP-PubSub Broker 158 Figure 1 shows an example architecture of a CoAP-PubSub capable 159 service. A Resource Directory (RD) service accepts registrations and 160 registration updates from one or more endpoints and hosts a resource 161 discovery service for one or more web application clients. State 162 information is updated from the endpoints to the CoAP-PubSub broker. 163 Web clients subscribe to the state of the endpoint from the CoAP- 164 PubSub broker, and publish updates to the endpoint state through the 165 CoAP-PubSub broker. The CoAP-PubSub broker performs a store-and- 166 forward function between web clients and the CoAP-PubSub capable 167 endpoints. The CoAP-PubSub broker is also responsible for acting as 168 a proxy, returning the last published value to web clients or other 169 endpoints on behalf endpoints that are sleeping. 171 Endpoints Service Applications 172 +------+ 173 | | 174 +- register -> | RD | <- discover -+ 175 +------+ | | | | +--------+ 176 | | --+ +------+ +-- | Web | 177 | EP | | Client | 178 | | <-+ +------+ +-> | app | 179 +------+ | | CoAP | | +--------+ 180 | EP | +-- pub/sub -> |PubSub| <- pub/sub --+ | app | 181 +------+ |Broker| +--------+ 182 +------+ 184 Figure 1: CoAP-PubSub Architecture 186 3.2. Client Endpoint 188 Client endpoints initiate all interactions with the RD and CoAP- 189 PubSub broker. If the endpoint is an actuator it will need to either 190 use CoAP Observe [I-D.ietf-core-observe] or periodically poll the 191 PubSub broker to check for updates. A CoAP-PubSub client endpoint 192 MUST use CoAP PUT operations to update its state on the PubSub 193 broker. An endpoint SHOULD update the RD periodically to indicate 194 that it is still alive even if it has no pending data updates. 195 Endpoints can operate in the client role even if not directly 196 reachable from the CoAP-PubSub broker or RD server. 198 3.3. Server Endpoint 200 Server endpoint interactions require the CoAP-PubSub broker to 201 perform the client role, initiating interaction with the server 202 endpoint. The CoAP-PubSub broker MAY then use PUT operations to 203 update state at the server endpoint, and MAY use GET or GET and 204 Observe to subscribe to resources at the endpoint. Server mode 205 endpoints are required to be reachable from the CoAP-PubSub broker. 206 In a network containing both client and server endpoints, client 207 endpoints MAY subscribe to server endpoints directly, in broker-less 208 configurations, using RD or core-link-format metadata in .well-known/ 209 core to discover the CoAP-PubSub capabilities and using GET and 210 Observe to subscribe to the desired topics. 212 3.4. Publish-Subscribe Topics 214 Topic are strings used to identify particular resources and objects 215 in publish-subscribe systems. Topics are conventionally formed as a 216 hierarchy, e.g. "/sensors/weather/barometer/pressure". 217 Implementations are free to map topics to resources, reusing existing 218 resource addressing schemes. 220 4. CoAP-PubSub Registration and discovery 222 An endpoint wishing to use a CoAP-PubSub broker registers with an RD 223 server that advertises a link with the rt="core.pubsub" attribute as 224 shown in Figure 2. This indicates that there is a CoAP-PubSub broker 225 at the location returned by the discovery query as shown in Figure 2. 226 The endpoint registers topics using the core link resource type (rt=) 227 "core.pubsub.client" or "core.pubsub.server" (or both) attributes to 228 indicate intention to use CoAP-PubSub and which modes are supported. 230 A server that implements a CoAP-PubSub broker MAY advertize this 231 capability by registering the rt="core.pubsub" with an associated 232 Resource Directory. If a server advertizes as a CoAP-PubSub Broker, 233 it MUST support the transactions described in section 5 of this 234 document. As server that implements the CoAP-PubSub Broker MAY also 235 implement sleeping endpoint and message queueing support referred to 236 in Section 6 of this document. 238 4.1. Register CoAP-PubSub Endpoint 240 Figure 2 shows the flow of the registration operation. Discovery 241 proceeds as per CoRE Resource Directory[I-D.ietf-core-resource- 242 directory-01]. When an endpoint wishes to use CoAP-PubSub, it 243 discovers the rt="core.pubsub" attribute at the RD service associated 244 with the CoAP-PubSub broker and registers its CoAP-PubSub resources 245 with the RD server by registering topics having the rt="core.pubsub" 246 attribute. Topics are created using an initial POST operation to the 247 registered topic or any valid sub-topic. For example, if the 248 registered topic is "/sensors/weather", the sub-topic 249 "/sensors/weather/barometer" is created using a POST to 250 "/pubsub/sensors/weather/barometer". An implementation MAY mix CoAP- 251 PubSub resources and CoAP REST resources on the same endpoint. 252 Endpoint registration proceeds as per normal RD registration. 254 EP Broker RD 255 | PubSub DISCOVERY | | 256 | ---- GET /.well-known/core?rt=core.pubsub --- | ------> | 257 | | | 258 | <--2.05 Content ";rt=core.pubsub"--- | ------- | 259 | | | 260 | | | 261 | TOPIC REGISTRATION | | 262 |POST /rd ";rt=core.pubsub.client"| ------> | 263 | | | 264 | <-------- 2.01 Created Location: /rd/1234 --- | ------- | 265 | | | 266 | | | 267 | FIRST PUBLISH | | 268 | ------------ POST /pubsub/0/... ------------> | | 269 | | | 270 | <--------------- 2.01 Created---------------- | | 271 | | | 273 Figure 2: Discovery and Registration 275 4.2. Unregister Endpoint 277 CoAP-PubSub endpoints indicate the end of their registration tenure 278 by either explicitly unregistering, as in Figure 3, or allowing the 279 lifetime of the previous registration to expire. 281 EP Broker RD 282 | | | 283 | UNREGISTER | | 284 | ---------------- DELETE /rd/1234 ------------ | ------> | 285 | | | 286 | <-------- 2.02 Deleted Location: /rd/1234 --- | ------- | 287 | | | 288 | | | 290 Figure 3: Unregister Endpoint 292 5. CoAP-PubSub Functions and Interactions 294 This section describes the transaction flows and interactions between 295 CoAP-PubSub endpoints and CoAP-PubSub brokers. Client endpoint 296 functions are used by endpoints implementing the client role, for 297 example to enable sleep/wakeup and partial connectivity. Server role 298 endpoint functions are used by endpoints implementing the server 299 role, for example always on, reachable, endpoints. An endpoint 300 implementation MAY support both client role and server role at an 301 endpoint. A CoAP-PubSub broker MUST implement support for both 302 client role and server role endpoints. 304 5.1. Client Role Endpoint Functions 306 This section describes the transaction flows and interactions between 307 CoAP-PubSub endpoints and CoAP-PubSub brokers where the endpoint 308 supports the client role. A client registering the 309 "core.pubsub.client" attribute MUST support the client role endpoint 310 functions and interactions described in this section. 312 5.1.1. Client Endpoint PUBLISH to CoAP-PubSub broker 314 Client endpoint PUBLISHes updates to CoAP-PubSub broker. A CoAP- 315 PubSub client endpoint MAY use PUT to publish state updates to the 316 CoAP-PubSub broker. 318 EP Broker RD 319 | | | 320 | | | 321 | PUBLISH | | 322 | -------------- PUT /pubsub/0/... -----------> | | 323 | | | 324 | | | 325 | <--------------- 2.04 Changed---------------- | | 326 | | | 327 | | | 329 Figure 4: Client Role PUBLISH from EP to Broker 331 5.1.2. Client Endpoint SUBSCRIBE, Broker PUBLISH 333 Client mode endpoint subscribes to the topic at the CoAP-PubSub 334 broker using GET and Observe. Published updates to the CoAP-PubSub 335 broker are published to the Endpoint using Observe response tokens. 336 Client endpoint MAY update actuator or resource based on received 337 values associated with responses. A CoAP-PubSub broker MUST publish 338 updates to subscribed endpoints upon receiving published updates on 339 the associated topics. 341 EP Broker RD 342 | | | 343 | | | 344 | SUBSCRIBE | | 345 | --- GET /pubsub/0/... Observe: Token:XX ----> | | 346 | | | 347 | PUBLISH | | 348 | <---------- 2.05 Content Observe:10---------- | | 349 | | | 350 | PUBLISH | | 351 | <---------- 2.05 Content Observe:12---------- | | 352 | | | 353 | PUBLISH | | 354 | <---------- 2.05 Content Observe:15---------- | | 355 | | | 356 | | | 358 Figure 5: Client Role Endpoint SUBSCRIBE, Broker PUBLISH to Endpoint 360 5.1.3. Client Endpoint GET from CoAP-PubSub Broker 362 Client mode endpoint MAY issue GET to topic without Observe as needed 363 to obtain last published state from the CoAP-PubSub broker. 365 EP Broker RD 366 | | | 367 | | | 368 | | | 369 | ------------- GET /pubsub/0/... ------------> | | 370 | | | 371 | | | 372 | <--------------- 2.05 Content --------------- | | 373 | | | 374 | | | 376 Figure 6: Client EP GET from CoAP-PubSub Broker 378 5.2. Server Role Endpoint Functions 380 This section describes the transaction flows and interactions between 381 CoAP-PubSub endpoints and CoAP-PubSub brokers where the endpoint 382 supports the server role. An endpoint registering the 383 "core.pubsub.server" attribute MUST support these functions and 384 interactions. 386 5.2.1. CoAP-PubSub broker SUBSCRIBES to Server Role EP 388 The server mode endpoint requires the CoAP-PubSub broker to act as a 389 client and subscribe to a resource on the endpoint using GET + 390 Observe. A CoAP-PubSub broker MAY subscribe to topics registered by 391 a server role endpoint at any time. A CoAP-PubSub broker MUST 392 subscribe to a topic registered by a server role endpoint upon 393 receiving a subscription on the associated topic. A CoAP-PubSub 394 broker MUST forward state updates received from a publishing endpoint 395 to all endpoints subscribed on the associated topic. Figure 7 shows 396 the flow of a CoAP-PubSub Broker subscribing to a server role 397 endpoint. 399 EP Broker RD 400 | | | 401 | | | 402 | SUBSCRIBE | | 403 | <------ GET /0/... Observe: Token:XX -------- | | 404 | | | 405 | PUBLISH | | 406 | ---------- 2.05 Content Observe:10----------> | | 407 | | | 408 | PUBLISH | | 409 | ---------- 2.05 Content Observe:12----------> | | 410 | | | 411 | PUBLISH | | 412 | ---------- 2.05 Content Observe:15----------> | | 413 | | | 414 | | | 416 Figure 7: Broker SUBSCRIBE to Server Role EP 418 5.2.2. CoAP-PubSub Broker Publishes to Server Role Endpoint 420 CoAP-PubSub broker MUST update server mode endpoint using PUT when 421 upon receiving updates published on the associated topics. Endpoint 422 server MAY update actuator or resource upon receiving published state 423 updates from the broker. 425 EP Broker RD 426 | | | 427 | | | 428 | PUBLISH | | 429 | <--------------- PUT /0/... ----------------- | | 430 | | | 431 | | | 432 | ---------------- 2.04 Changed---------------> | | 433 | | | 434 | | | 436 Figure 8: Broker PUBLISH to Server Role EP 438 5.2.3. CoAP-PubSub Broker GET from Server Role Endpoint 440 CoAP-PubSub broker MAY issue GET without Observe as needed to obtain 441 state update from the server role endpoint. 443 EP Broker RD 444 | | | 445 | | | 446 | | | 447 | <---------------- GET /0/... ---------------- | | 448 | | | 449 | | | 450 | ---------------- 2.05 Content --------------> | | 451 | | | 452 | | | 454 Figure 9: Broker GET from Server Role Endpoint 456 6. Enabling Multiple Publishers 458 6.1. Creating a Topic 460 After registration of the EP in the RD and discovering the CoAP- 461 PubSub function, a designated EP acting as publisher for a particular 462 topic is responsible for creating such topic. To do so, it will have 463 to register the new topic in the RD and create it on the PubSub 464 function by doing a first publication as shown in Figure 2. 466 After the topic has been created in the CoAP-PubSub broker, the 467 broker will be responsible of hosting this resource and to queue 468 messages published on it as explained in Section 5 470 6.2. Publishing a Topic from Multiple Publishers 472 After the topic has been registered in the RD and is created in the 473 CoAP-PubSub broker, any device with the right access permissions can 474 publish on that topic by using the topic field. For example in the 475 following diagram, both EP1 and EP2 update the same topic that EP3 476 has previously subscribed to. 478 After the topic has been created in the CoAP-PubSub Broker, the 479 broker will be responsible of hosting this resource and to queue 480 messages published on it as explained in Section 5 481 EP1 EP2 Broker 482 | | PUBLISH | 483 | ------------ PUT /pubsub/0/TOPIC1 ----------> | 484 | | | 485 | <--------------- 2.04 Changed---------------- | 486 | | | 487 | | PUBLISH | 488 | | ---- PUT /pubsub/0/TOPIC1 ----------> | 489 | | | 490 | | <------- 2.04 Changed---------------- | 491 | | | 493 Figure 10: Multiple CoAP-PubSub EPs PUBLISH to Broker 495 6.3. Subscribing to a topic with multiple publishers 497 Subscription to this topic is the same as in Section 5, since it acts 498 as any other resource. Following the previous example, if EP3 is 499 subscribed to the shared topic, it should receive two updates from 500 both EP1 and EP2. 502 EP3 Broker 503 | SUBSCRIBE | 504 | ----- GET /pubsub/0/TOPIC1 Observe ---------> | 505 | | 506 | PUBLISH | 507 | <----------- 2.05 Content EP1 -------------- | 508 | | 509 | PUBLISH | 510 | <----------- 2.05 Content EP2 -------------- | 511 | | 513 Figure 11: CoAP-PubSub Endpoint SUBSCRIBE to Broker 515 7. Sleep-Wakeup Operation and Message Queueing 517 A CoAP-PubSub broker MAY implement support for sleeping endpoints and 518 queueing of messages as provided for in [OMALightweightM2M] 520 8. Security Considerations 522 CoAP-PubSub re-uses CoAP [RFC7252], CoRE Resource Directory 523 [I-D.ietf-core-resource-directory], and Web Linking [RFC5988] and 524 therefore the security considerations of those documents also apply 525 to this specification. Additionally, a CoAP-PubSub broker and the 526 endpoints SHOULD authenticate each other and enforce access control 527 policies. A malicious EP could subscribe to data it is not 528 authorized to or mount a denial of service attack against the broker 529 by publishing a large number of resources. The authentication can be 530 performed using the already standardized DTLS offered mechanisms, 531 such as certificates. DTLS also allows communication security to be 532 established to ensure integrity and confidentiality protection of the 533 data exchanged between these relevant parties. Provisioning the 534 necessary credentials, trust anchors and authorization policies is 535 non-trivial and subject of ongoing work. 537 The use of a CoAP-PubSub broker introduces challenges for the use of 538 end-to-end security between the end device and the cloud-based server 539 infrastructure since brokers terminate the exchange. While running 540 separate DTLS sessions from the EP to the broker and from broker to 541 the web application protects confidentially on those paths, the 542 client/server EP does not know whether the commands coming from the 543 broker are actually coming from the client web application. 544 Similarly, a client web application requesting data does not know 545 whether the data originated on the server EP. For scenarios where 546 end-to-end security is desirable the use of application layer 547 security is unavoidable. Application layer security would then 548 provide a guarantee to the client EP that any request originated at 549 the client web application. Similarly, integrity protected sensor 550 data from a server EP will also provide guarantee to the client web 551 application that the data originated on the EP itself. The protected 552 data can also be verified by the intermediate broker ensuring that it 553 stores/caches correct request/response and no malicious messages/ 554 requests are accepted. The broker would still be able to perform 555 aggregation of data/requests collected. 557 Depending on the level of trust users and system designers place in 558 the CoAP-PubSub broker, the use of end-to-end encryption may also be 559 envisioned. The CoAP-PubSub broken would then only be able to verify 560 the request/response message/commands and store-and-forward without 561 being able to inspect the content. The solution for providing 562 application layer security will depend on the utilized data encoding. 563 For example, with a JSON-based data encoding the work from the JOSE 564 working group could be re-used. Distribution of the credentials for 565 accomplishing end-to-end security might introduce challenges if 566 previously unknown parties need to exchange data. 568 9. IANA Considerations 570 This document registers two attribute values in the Resource Type 571 (rt=) registry established with RFC 6690 [RFC6690]. 573 9.1. Resource Type value 'core.pubsub.client' 575 o Attribute Value: core.pubsub.client 577 o Description: Section X of [[This document]] 579 o Reference: [[This document]] 581 o Notes: None 583 9.2. Resource Type value 'core.pubsub.server' 585 o Attribute Value: core.pubsub.server 587 o Description: Section Y of [[This document]] 589 o Reference: [[This document]] 591 o Notes: None 593 10. Acknowledgements 595 The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit 596 Sethi, and Anders Eriksson for their contributions and reviews 598 11. References 600 11.1. Normative References 602 [I-D.ietf-core-observe] 603 Hartke, K., "Observing Resources in CoAP", draft-ietf- 604 core-observe-14 (work in progress), June 2014. 606 [I-D.ietf-core-resource-directory] 607 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 608 Directory", draft-ietf-core-resource-directory-01 (work in 609 progress), December 2013. 611 [OMALightweightM2M] 612 Open Mobile Alliance, "OMA LightweightM2M v1.0", 613 http://technical.openmobilealliance.org/Technical/ 614 technical-information/release-program/current-releases/ 615 oma-lightweightm2m-v1-0, 12 2013. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 621 and D. Orchard, "URI Template", RFC 6570, March 2012. 623 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 624 Format", RFC 6690, August 2012. 626 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 627 Application Protocol (CoAP)", RFC 7252, June 2014. 629 11.2. Informative References 631 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 633 Authors' Addresses 635 Michael Koster 636 ARM Limited 638 Email: Michael.Koster@arm.com 640 Ari Keranen 641 Ericsson 643 Email: ari.keranen@ericsson.com 645 Jaime Jimenez 646 Ericsson 648 Email: jaime.jimenez@ericsson.com