idnits 2.17.1 draft-hartke-t2trg-data-hub-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2720 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-hartke-core-apps-05 == Outdated reference: A later version (-09) exists of draft-hartke-t2trg-coral-01 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-09 -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Thing-to-Thing Research Group K. Hartke 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Experimental November 13, 2016 5 Expires: May 17, 2017 7 Thing-to-Thing Data Hub 8 draft-hartke-t2trg-data-hub-00 10 Abstract 12 A Thing-to-Thing Data Hub is a RESTful, hypermedia-driven Web 13 application that can be used in Thing-to-Thing communication to 14 share information such as thing descriptions, configurations, 15 resource descriptions or sleep schedules at a central location. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 17, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Data Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Interaction Model . . . . . . . . . . . . . . . . . . . . 5 56 2.3. Application Description . . . . . . . . . . . . . . . . . 6 57 3. Interoperability Considerations . . . . . . . . . . . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 6.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 9 64 A.1. CoRE Lighting . . . . . . . . . . . . . . . . . . . . . . 9 65 A.2. CoAP Publish-Subscribe . . . . . . . . . . . . . . . . . 10 66 A.3. CoRE Resource Directory . . . . . . . . . . . . . . . . . 12 67 A.4. CoRE Mirror Server . . . . . . . . . . . . . . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 In Thing-to-Thing communication, there is often a need to share 73 information of common interest at a central location. For example, a 74 CoRE Resource Directory [I-D.ietf-core-resource-directory] aggregates 75 descriptions of resources held on other servers, which enables things 76 to easily discover these resources. Similarly, a W3C Web-of-Things 77 Thing Description Repository [WOT] stores the semantic metadata of 78 things as well as functional descriptions of their interfaces, making 79 this information available to Web dashboards, commissioning tools and 80 other things. 82 As more and more thing-to-thing applications are implemented, it 83 becomes increasingly important to be able to share also other data 84 than resource and thing descriptions, such as the sleep schedules of 85 devices, default configurations for new devices, firmware update 86 notices, or certificate revocation lists. Resource directory and 87 thing description repository are not always the best fit for this 88 kind of data and defining a new specialized application for each use 89 case is not practical in the long term. 91 This document defines a simple "data hub" application, a RESTful Web 92 application suitable for constrained environments that generalizes 93 the concept of a central entity for sharing information. A data hub 94 enables clients to share data items in any media type and provides 95 means for creating, reading, observing, updating, deleting and 96 finding shared items at a data hub server. 98 The application is presented in the style of a CoRE Application 99 Description [I-D.hartke-core-apps]. That is, the focus of the 100 application interface is on the media types used by the data hub and 101 all interactions are driven by links and forms. 103 Features: 105 o General 107 The generalization to any media type provides two advantages. The 108 first is media type agility: applications using the data hub won't 109 be stuck forever with the same media types. The second, as 110 mentioned above, is that it may be useful to share also other 111 information than resource and thing descriptions. 113 o Searchable 115 Submitting a search query allows clients to retrieve a subset of 116 items from a data hub. Without this feature, a client would have 117 to download and sort through the whole set of shared items. It is 118 more efficient to filter the set at the data hub server. To make 119 this work with any media type, a search request needs to specify 120 both the media type of the desired items and a media type-specific 121 search query. 123 o Observable 125 The items published to a data hub are exposed as resources and as 126 such can be observed for changes [RFC7641]. This allows clients 127 to stay informed of information that other clients update over a 128 period of time. In effect, the data hub is similar in functioning 129 to a CoAP Publish-Subscribe Broker [I-D.ietf-core-coap-pubsub], 130 although this isn't the primary use case of a data hub. 132 o Evolvable 134 The key differentiator of the data hub compared to resource 135 directory and publish-subscribe broker lies in the evolvability -- 136 the ability to respond effectively to change (such as the addition 137 of new features) without negatively impacting both existing and 138 new clients. The definition of the application interfaces purely 139 in terms of standardized URI templates makes it very difficult to 140 gradually evolve them; there are no versioning or capability 141 negotiation mechanisms. The data hub facilitates fine-grained 142 evolvability by driving all interactions by machine-understandable 143 hypertext. Features can be added, changed or removed in a safe, 144 backwards-compatible way simply by updating the data hub 145 representation to expose matching links and forms. 147 1.1. Terminology 149 Readers are expected to be familiar with the terms and concepts 150 described in [RFC5988], [RFC6573], and [I-D.hartke-core-apps]. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119]. 157 2. Data Hubs 159 This section defines the data model and the interaction model of data 160 hubs. 162 2.1. Data Model 164 The data model consists of two elements: the data hub and a number of 165 shared items (Figure 1). 167 ___ 168 Data / \ 169 Hub \___/ ___ 170 |__________/ \ Item 1 171 | item \___/ 172 | ___ 173 |__________/ \ Item 2 174 | item \___/ 175 | . 176 | . 177 | . 178 | ___ 179 |__________/ \ Item N 180 item \___/ 182 Figure 1: A Data Hub with a Number of Shared Items 184 Data Hub 186 A data hub is a Web application intended for sharing information. 187 Things can leave and erase data items for other things to read and 188 see. 190 A data hub resource is a collection of shared data items. Its 191 representation primarily consists of links to the data item 192 resources using the "item" link relation type [RFC6573]. To 193 reduce the number of round-trips, it MAY also embed (complete or 194 partial) representations of those item resources. Forms contained 195 in the representation enable interactions with the hub and items. 197 For a start, a data hub has only a depth of one level; i.e., all 198 data item resources are organized directly under the top-level 199 data hub resource. This could be extended to multiple levels in a 200 future revision of this draft. 202 Data hub representations are formatted in the "application/coral" 203 media type [I-D.hartke-t2trg-coral]. 205 Item 207 A data hub item is a member of the collection. 209 Item representations can in principle be formatted in any media 210 type; a data hub deployment MAY restrict the media types it 211 accepts for publication, though. 213 The representations of items MAY link back to a data hub resource 214 using the "collection" link relation type [RFC6573]. 216 2.2. Interaction Model 218 The interaction model consists of eight possible interactions with a 219 data hub: discovering and reading the data hub, and creating, 220 reading, observing, updating, deleting and finding shared items in 221 the data hub. 223 Discovery 225 For a start, nodes are assumed to be pre-configured out-of-band 226 with a link to a data hub. 228 Read Data Hub 230 A node can retrieve a representation of the data hub by following 231 the discovered link. The representation of the data hub includes 232 links to (and/or literals with representations of) the items in 233 the data hub. The data hub representation MAY also include forms 234 for creating, updating, deleting and finding items. 236 Create Item 238 The representation of a data hub MAY contain a form with the 239 "create-item" form relation type. Submitting this form with a 240 representation in one of the accepted content formats creates a 241 new item in the data hub. 243 Read Item 245 A node can retrieve a representation of an item by following one 246 of the links with the "item" link relation type in the 247 representation of the data hub. 249 Observe Item 251 A node can observe an item by following one of the links with the 252 "item" link relation type in the representation of the data hub 253 and observing the target resource as specified in [RFC7641]. 255 Update Item 257 For each item in a data hub, the representation of the data hub 258 MAY indicate that the item is updatable. If an item is updatable, 259 the link to the item includes the CoRAL Updatable Option, which 260 defines a form with the "update" form relation type. Submitting 261 this form updates the item in the data hub to the submitted 262 representation. 264 Delete Item 266 For each item in a data hub, the representation of the data hub 267 MAY indicate that the item is deletable. If an item is deletable, 268 the link to the item includes the CoRAL Deletable Option, which 269 defines a form with the "delete" form relation type. Submitting 270 this form deletes the item from the data hub. 272 Find Items 274 A form with the "search" form relation type can be used to find 275 items. Submitting this form with a media type and a media type- 276 specific filter query returns a subset of the data hub that 277 matches the filter. 279 (The details of this are TODO.) 281 2.3. Application Description 283 Application name: 284 Thing-to-Thing Data Hub 1.0 286 URI schemes: 287 coap [RFC7252] 289 Media types: 290 application/coral [I-D.hartke-t2trg-coral] 292 Link relation types: 293 collection [RFC6573] 294 item [RFC6573] 296 Form relation types: 297 create-item [I-D.hartke-core-apps] 298 update [I-D.hartke-core-apps] 299 delete [I-D.hartke-core-apps] 300 search [I-D.hartke-core-apps] 302 Form field names: 303 None. 305 Well-known locations: 306 None. 308 Interoperability considerations: 309 See Section 3. 311 Security considerations: 312 See Section 4. 314 Contact: 315 See "Author's Address" section. 317 Author/Change controller: 318 IESG 320 3. Interoperability Considerations 322 TODO. 324 4. Security Considerations 326 TODO. 328 5. IANA Considerations 330 This document includes no request to IANA. 332 6. References 334 6.1. Normative References 336 [I-D.hartke-core-apps] 337 Hartke, K., "CoRE Application Descriptions", draft-hartke- 338 core-apps-05 (work in progress), October 2016. 340 [I-D.hartke-t2trg-coral] 341 Hartke, K., "The Constrained RESTful Application Language 342 (CoRAL)", draft-hartke-t2trg-coral-01 (work in progress), 343 October 2016. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC6573] Amundsen, M., "The Item and Collection Link Relations", 351 RFC 6573, DOI 10.17487/RFC6573, April 2012, 352 . 354 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 355 Application Protocol (CoAP)", RFC 7252, 356 DOI 10.17487/RFC7252, June 2014, 357 . 359 [RFC7641] Hartke, K., "Observing Resources in the Constrained 360 Application Protocol (CoAP)", RFC 7641, 361 DOI 10.17487/RFC7641, September 2015, 362 . 364 6.2. Informative References 366 [I-D.hartke-core-lighting] 367 Hartke, K., "CoRE Lighting", draft-hartke-core-lighting-00 368 (work in progress), September 2015. 370 [I-D.ietf-core-coap-pubsub] 371 Koster, M., Keranen, A., and J. Jimenez, "Publish- 372 Subscribe Broker for the Constrained Application Protocol 373 (CoAP)", draft-ietf-core-coap-pubsub-00 (work in 374 progress), October 2016. 376 [I-D.ietf-core-resource-directory] 377 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 378 Resource Directory", draft-ietf-core-resource-directory-09 379 (work in progress), October 2016. 381 [I-D.vial-core-mirror-server] 382 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 383 server-01 (work in progress), April 2013. 385 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 386 DOI 10.17487/RFC5988, October 2010, 387 . 389 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 390 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 391 . 393 [WOT] Kovatsch, M. and D. Peintner, "WoT Current Practices", 394 November 2016, . 397 Appendix A. Related Work 399 The data hub is an instance of the well-known collection pattern. As 400 such, it might be used in places where a more specialized instance of 401 the collection pattern is currently used, such as the bulletin board 402 of CoRE Lighting [I-D.hartke-core-lighting], the CoAP Publish- 403 Subscribe Broker [I-D.ietf-core-coap-pubsub], or the CoRE Resource 404 Directory [I-D.ietf-core-resource-directory]. This section shows how 405 these might be implemented using a data hub (without trying to 406 replicate all of their features in detail). 408 A.1. CoRE Lighting 410 CoRE Lighting [I-D.hartke-core-lighting] uses a JSON-based "bulletin 411 board" to discover things such as light bulbs and light switches. 412 Things are described by a thing description that contains both human- 413 readable information and machine-understandable hypermedia controls 414 which indicate the possible interactions with the thing. 416 +----------------------------------+ 417 | ___ | 418 | / \ Data Hub | 419 | \___/ ___ | 420 | |__________/ \ Thing | +------------------------+ 421 | | item \___/ Description | | ___ | 422 | | |________________|____|__/ \ Light Bulb | 423 | | config | | \___/ Configuration | 424 | | | | | 425 | | ___ | +------------------------+ 426 | |__________/ \ Thing | +------------------------+ 427 | item \___/ Description | | ___ | 428 | |________________|____|__/ \ Light Remote | 429 | about | | \___/ Control State | 430 | | | | 431 +----------------------------------+ +------------------------+ 433 Figure 2: A Data Hub Storing Thing Descriptions 435 Figure 2 shows a data hub with two thing descriptions, matching the 436 example in Section 5.2.1 of [I-D.hartke-core-lighting]. The first 437 thing description describes a light bulb and has a link with the 438 "config" link relation type pointing to the configuration of the 439 light bulb. The second thing description describes a light remote 440 control (LRC) and has a link with the "about" link relation type 441 pointing to the observable state of the LRC. 443 Thing descriptions are represented in the "application/thing- 444 description+json" media type (content format 65200 in the example). 445 A data hub representation thus could look as shown in Figure 3. 447 ______________________________ 448 | | 449 | Form | 450 | relation: 1 (create-item) | 451 | method: 2 (POST) | 452 | accept: 65200 | 453 |______________________________| 454 | | 455 | Literal | 456 | relation: 33 (item) | 457 | format: 65200 | 458 | ________________________ | 459 | | | | 460 | | Thing Description 1 | | 461 | |________________________| | 462 |______________________________| 463 | | 464 | Literal | 465 | relation: 33 (item) | 466 | format: 65200 | 467 | ________________________ | 468 | | | | 469 | | Thing Description 2 | | 470 | |________________________| | 471 |______________________________| 473 Figure 3: A Data Hub Representation With Two Thing Descriptions 475 A.2. CoAP Publish-Subscribe 477 CoAP Publish-Subscribe [I-D.ietf-core-coap-pubsub] provides means for 478 sensor and actuator nodes with limited reachability to publish and 479 receive data without having to be reachable at the same time. The 480 basic operation involves clients called "publishers" updating "topic" 481 resources at a server called the "broker", and clients called 482 "subscribers" observing these resources (Figure 4). 484 ____________ ____________ ____________ 485 | |--------->| | | | 486 | Publisher |<---------| Broker | | Subscriber | 487 | (Client) | | (Server) |<---------| (Client) | 488 |____________| |____________|--------->|____________| 490 Figure 4: CoAP Publish-Subscribe 492 A broker might be implemented as a data hub by creating the topics as 493 resources on the data hub server and linking to these from the data 494 hub resource with the "item" link relation type (Figure 5). 495 Hypermedia controls in the data hub representation enable publishers 496 to create, update and delete topics, and subscribers to read/observe 497 these topics. 499 +------------------------------+ 500 | ___ | 501 | / \ Data Hub | 502 | \___/ ___ | 503 | |__________/ \ Topic A | 504 | | item \___/ | 505 | | ___ | 506 | |__________/ \ Topic B | 507 | | item \___/ | 508 | | ___ | 509 | |__________/ \ Topic C | 510 | item \___/ | 511 | | 512 +------------------------------+ 514 Figure 5: A Data Hub Acting as a Publish-Subscribe Broker 516 +-------------+------------------+ 517 | Interaction | Mapped to | 518 +-------------+------------------+ 519 | DISCOVER | Discovery / | 520 | | Read Data Hub / | 521 | | Find Items | 522 | CREATE | Create Item | 523 | PUBLISH | Update Item | 524 | SUBSCRIBE | Observe Item | 525 | UNSUBSCRIBE | Observe Item | 526 | READ | Read Item | 527 | REMOVE | Delete Item | 528 +-------------+------------------+ 530 Table 1: Mapping of Pub/Sub Interactions to Data Hub 532 A.3. CoRE Resource Directory 534 A CoRE Resource Directory [I-D.ietf-core-resource-directory] hosts 535 descriptions of resources held on other servers, allowing lookups to 536 be performed for those descriptions. The descriptions are encoded as 537 links in CoRE Link Format [RFC6690] that are annotated with a variety 538 of link attributes providing the type of and hints about the linked 539 resources. 541 +----------------------------------+ 542 | ___ | 543 | / \ Data Hub | 544 | \___/ ___ | 545 | |__________/ \ Link Format | +------------------------+ 546 | | item \___/ Resource | | ___ | 547 | | |________________|____|__/ \ Resource A | 548 | | hosts | | \___/ | 549 | | | | | 550 | | ___ | +------------------------+ 551 | |__________/ \ Link Format | +------------------------+ 552 | item \___/ Resource | | ___ | 553 | |________________|____|__/ \ Resource B | 554 | hosts | | \___/ | 555 | | | | 556 +----------------------------------+ +------------------------+ 558 Figure 6: A Data Hub Storing Links 560 A data hub might store these resource descriptions such that each 561 resource description becomes one item in the data hub and each item 562 links to the respective resource (Figure 6). 564 +-----------------------+-------------+ 565 | Interaction | Mapped to | 566 +-----------------------+-------------+ 567 | Discovery | Discovery | 568 | Registration | Create Item | 569 | Update | Update Item | 570 | Removal | Delete Item | 571 | Read Endpoint Links | - | 572 | Update Endpoint Links | - | 573 | Register a Group | - | 574 | Group Removal | - | 575 | Lookup | Find Items | 576 +-----------------------+-------------+ 578 Table 2: Mapping of Resource Directory Interactions to Data Hub 580 A.4. CoRE Mirror Server 582 Similar to a CoAP Publish-Subscribe Broker, a CoRE Mirror Server 583 [I-D.vial-core-mirror-server] allows a sleepy device to store 584 representations of their resources so that other devices can access 585 the representations while it is sleeping. 587 +----------------------------------+ 588 | ___ | 589 | / \ Data Hub | 590 | \___/ ___ | 591 | |___________/ \ Mirrored | 592 | | item \___/ Resource A | 593 | | ___ | 594 | |___________/ \ Mirrored | 595 | | item \___/ Resource B | 596 | | ___ | 597 | |___________/ \ Mirrored | 598 | item \___/ Resource C | 599 | | 600 +----------------------------------+ 602 Figure 7: A Data Hub Acting as a Mirror Server 604 +----------------------------+-------------+ 605 | Interaction | Mapped to | 606 +----------------------------+-------------+ 607 | Discovery | Discovery | 608 | Registration | Create Item | 609 | Removal | Delete Item | 610 | Update Mirrored Resource | Update Item | 611 | Retrieve Mirrored Resource | Read Item | 612 +----------------------------+-------------+ 614 Table 3: Mapping of Mirror Server Interactions to Data Hub 616 Author's Address 618 Klaus Hartke 619 Universitaet Bremen TZI 620 Postfach 330440 621 Bremen D-28359 622 Germany 624 Phone: +49-421-218-63905 625 Email: hartke@tzi.org