Thing-to-Thing Research Group K. Hartke Internet-Draft Universitaet Bremen TZI Intended status: Experimental November 13, 2016 Expires: May 17, 2017 Thing-to-Thing Data Hub draft-hartke-t2trg-data-hub-00 Abstract A Thing-to-Thing Data Hub is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communication to share information such as thing descriptions, configurations, resource descriptions or sleep schedules at a central location. 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 May 17, 2017. Copyright Notice Copyright (c) 2016 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 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. Hartke Expires May 17, 2017 [Page 1] Internet-Draft Thing-to-Thing Data Hub November 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Data Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Interaction Model . . . . . . . . . . . . . . . . . . . . 5 2.3. Application Description . . . . . . . . . . . . . . . . . 6 3. Interoperability Considerations . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 9 A.1. CoRE Lighting . . . . . . . . . . . . . . . . . . . . . . 9 A.2. CoAP Publish-Subscribe . . . . . . . . . . . . . . . . . 10 A.3. CoRE Resource Directory . . . . . . . . . . . . . . . . . 12 A.4. CoRE Mirror Server . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In Thing-to-Thing communication, there is often a need to share information of common interest at a central location. For example, a CoRE Resource Directory [I-D.ietf-core-resource-directory] aggregates descriptions of resources held on other servers, which enables things to easily discover these resources. Similarly, a W3C Web-of-Things Thing Description Repository [WOT] stores the semantic metadata of things as well as functional descriptions of their interfaces, making this information available to Web dashboards, commissioning tools and other things. As more and more thing-to-thing applications are implemented, it becomes increasingly important to be able to share also other data than resource and thing descriptions, such as the sleep schedules of devices, default configurations for new devices, firmware update notices, or certificate revocation lists. Resource directory and thing description repository are not always the best fit for this kind of data and defining a new specialized application for each use case is not practical in the long term. This document defines a simple "data hub" application, a RESTful Web application suitable for constrained environments that generalizes the concept of a central entity for sharing information. A data hub enables clients to share data items in any media type and provides means for creating, reading, observing, updating, deleting and finding shared items at a data hub server. Hartke Expires May 17, 2017 [Page 2] Internet-Draft Thing-to-Thing Data Hub November 2016 The application is presented in the style of a CoRE Application Description [I-D.hartke-core-apps]. That is, the focus of the application interface is on the media types used by the data hub and all interactions are driven by links and forms. Features: o General The generalization to any media type provides two advantages. The first is media type agility: applications using the data hub won't be stuck forever with the same media types. The second, as mentioned above, is that it may be useful to share also other information than resource and thing descriptions. o Searchable Submitting a search query allows clients to retrieve a subset of items from a data hub. Without this feature, a client would have to download and sort through the whole set of shared items. It is more efficient to filter the set at the data hub server. To make this work with any media type, a search request needs to specify both the media type of the desired items and a media type-specific search query. o Observable The items published to a data hub are exposed as resources and as such can be observed for changes [RFC7641]. This allows clients to stay informed of information that other clients update over a period of time. In effect, the data hub is similar in functioning to a CoAP Publish-Subscribe Broker [I-D.ietf-core-coap-pubsub], although this isn't the primary use case of a data hub. o Evolvable The key differentiator of the data hub compared to resource directory and publish-subscribe broker lies in the evolvability -- the ability to respond effectively to change (such as the addition of new features) without negatively impacting both existing and new clients. The definition of the application interfaces purely in terms of standardized URI templates makes it very difficult to gradually evolve them; there are no versioning or capability negotiation mechanisms. The data hub facilitates fine-grained evolvability by driving all interactions by machine-understandable hypertext. Features can be added, changed or removed in a safe, backwards-compatible way simply by updating the data hub representation to expose matching links and forms. Hartke Expires May 17, 2017 [Page 3] Internet-Draft Thing-to-Thing Data Hub November 2016 1.1. Terminology Readers are expected to be familiar with the terms and concepts described in [RFC5988], [RFC6573], and [I-D.hartke-core-apps]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Data Hubs This section defines the data model and the interaction model of data hubs. 2.1. Data Model The data model consists of two elements: the data hub and a number of shared items (Figure 1). ___ Data / \ Hub \___/ ___ |__________/ \ Item 1 | item \___/ | ___ |__________/ \ Item 2 | item \___/ | . | . | . | ___ |__________/ \ Item N item \___/ Figure 1: A Data Hub with a Number of Shared Items Data Hub A data hub is a Web application intended for sharing information. Things can leave and erase data items for other things to read and see. A data hub resource is a collection of shared data items. Its representation primarily consists of links to the data item resources using the "item" link relation type [RFC6573]. To reduce the number of round-trips, it MAY also embed (complete or Hartke Expires May 17, 2017 [Page 4] Internet-Draft Thing-to-Thing Data Hub November 2016 partial) representations of those item resources. Forms contained in the representation enable interactions with the hub and items. For a start, a data hub has only a depth of one level; i.e., all data item resources are organized directly under the top-level data hub resource. This could be extended to multiple levels in a future revision of this draft. Data hub representations are formatted in the "application/coral" media type [I-D.hartke-t2trg-coral]. Item A data hub item is a member of the collection. Item representations can in principle be formatted in any media type; a data hub deployment MAY restrict the media types it accepts for publication, though. The representations of items MAY link back to a data hub resource using the "collection" link relation type [RFC6573]. 2.2. Interaction Model The interaction model consists of eight possible interactions with a data hub: discovering and reading the data hub, and creating, reading, observing, updating, deleting and finding shared items in the data hub. Discovery For a start, nodes are assumed to be pre-configured out-of-band with a link to a data hub. Read Data Hub A node can retrieve a representation of the data hub by following the discovered link. The representation of the data hub includes links to (and/or literals with representations of) the items in the data hub. The data hub representation MAY also include forms for creating, updating, deleting and finding items. Create Item The representation of a data hub MAY contain a form with the "create-item" form relation type. Submitting this form with a representation in one of the accepted content formats creates a new item in the data hub. Hartke Expires May 17, 2017 [Page 5] Internet-Draft Thing-to-Thing Data Hub November 2016 Read Item A node can retrieve a representation of an item by following one of the links with the "item" link relation type in the representation of the data hub. Observe Item A node can observe an item by following one of the links with the "item" link relation type in the representation of the data hub and observing the target resource as specified in [RFC7641]. Update Item For each item in a data hub, the representation of the data hub MAY indicate that the item is updatable. If an item is updatable, the link to the item includes the CoRAL Updatable Option, which defines a form with the "update" form relation type. Submitting this form updates the item in the data hub to the submitted representation. Delete Item For each item in a data hub, the representation of the data hub MAY indicate that the item is deletable. If an item is deletable, the link to the item includes the CoRAL Deletable Option, which defines a form with the "delete" form relation type. Submitting this form deletes the item from the data hub. Find Items A form with the "search" form relation type can be used to find items. Submitting this form with a media type and a media type- specific filter query returns a subset of the data hub that matches the filter. (The details of this are TODO.) 2.3. Application Description Application name: Thing-to-Thing Data Hub 1.0 URI schemes: coap [RFC7252] Media types: application/coral [I-D.hartke-t2trg-coral] Hartke Expires May 17, 2017 [Page 6] Internet-Draft Thing-to-Thing Data Hub November 2016 Link relation types: collection [RFC6573] item [RFC6573] Form relation types: create-item [I-D.hartke-core-apps] update [I-D.hartke-core-apps] delete [I-D.hartke-core-apps] search [I-D.hartke-core-apps] Form field names: None. Well-known locations: None. Interoperability considerations: See Section 3. Security considerations: See Section 4. Contact: See "Author's Address" section. Author/Change controller: IESG 3. Interoperability Considerations TODO. 4. Security Considerations TODO. 5. IANA Considerations This document includes no request to IANA. 6. References 6.1. Normative References [I-D.hartke-core-apps] Hartke, K., "CoRE Application Descriptions", draft-hartke- core-apps-05 (work in progress), October 2016. Hartke Expires May 17, 2017 [Page 7] Internet-Draft Thing-to-Thing Data Hub November 2016 [I-D.hartke-t2trg-coral] Hartke, K., "The Constrained RESTful Application Language (CoRAL)", draft-hartke-t2trg-coral-01 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6573] Amundsen, M., "The Item and Collection Link Relations", RFC 6573, DOI 10.17487/RFC6573, April 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . 6.2. Informative References [I-D.hartke-core-lighting] Hartke, K., "CoRE Lighting", draft-hartke-core-lighting-00 (work in progress), September 2015. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-ietf-core-coap-pubsub-00 (work in progress), October 2016. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", draft-ietf-core-resource-directory-09 (work in progress), October 2016. [I-D.vial-core-mirror-server] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- server-01 (work in progress), April 2013. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . Hartke Expires May 17, 2017 [Page 8] Internet-Draft Thing-to-Thing Data Hub November 2016 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [WOT] Kovatsch, M. and D. Peintner, "WoT Current Practices", November 2016, . Appendix A. Related Work The data hub is an instance of the well-known collection pattern. As such, it might be used in places where a more specialized instance of the collection pattern is currently used, such as the bulletin board of CoRE Lighting [I-D.hartke-core-lighting], the CoAP Publish- Subscribe Broker [I-D.ietf-core-coap-pubsub], or the CoRE Resource Directory [I-D.ietf-core-resource-directory]. This section shows how these might be implemented using a data hub (without trying to replicate all of their features in detail). A.1. CoRE Lighting CoRE Lighting [I-D.hartke-core-lighting] uses a JSON-based "bulletin board" to discover things such as light bulbs and light switches. Things are described by a thing description that contains both human- readable information and machine-understandable hypermedia controls which indicate the possible interactions with the thing. +----------------------------------+ | ___ | | / \ Data Hub | | \___/ ___ | | |__________/ \ Thing | +------------------------+ | | item \___/ Description | | ___ | | | |________________|____|__/ \ Light Bulb | | | config | | \___/ Configuration | | | | | | | | ___ | +------------------------+ | |__________/ \ Thing | +------------------------+ | item \___/ Description | | ___ | | |________________|____|__/ \ Light Remote | | about | | \___/ Control State | | | | | +----------------------------------+ +------------------------+ Figure 2: A Data Hub Storing Thing Descriptions Figure 2 shows a data hub with two thing descriptions, matching the example in Section 5.2.1 of [I-D.hartke-core-lighting]. The first Hartke Expires May 17, 2017 [Page 9] Internet-Draft Thing-to-Thing Data Hub November 2016 thing description describes a light bulb and has a link with the "config" link relation type pointing to the configuration of the light bulb. The second thing description describes a light remote control (LRC) and has a link with the "about" link relation type pointing to the observable state of the LRC. Thing descriptions are represented in the "application/thing- description+json" media type (content format 65200 in the example). A data hub representation thus could look as shown in Figure 3. ______________________________ | | | Form | | relation: 1 (create-item) | | method: 2 (POST) | | accept: 65200 | |______________________________| | | | Literal | | relation: 33 (item) | | format: 65200 | | ________________________ | | | | | | | Thing Description 1 | | | |________________________| | |______________________________| | | | Literal | | relation: 33 (item) | | format: 65200 | | ________________________ | | | | | | | Thing Description 2 | | | |________________________| | |______________________________| Figure 3: A Data Hub Representation With Two Thing Descriptions A.2. CoAP Publish-Subscribe CoAP Publish-Subscribe [I-D.ietf-core-coap-pubsub] provides means for sensor and actuator nodes with limited reachability to publish and receive data without having to be reachable at the same time. The basic operation involves clients called "publishers" updating "topic" resources at a server called the "broker", and clients called "subscribers" observing these resources (Figure 4). Hartke Expires May 17, 2017 [Page 10] Internet-Draft Thing-to-Thing Data Hub November 2016 ____________ ____________ ____________ | |--------->| | | | | Publisher |<---------| Broker | | Subscriber | | (Client) | | (Server) |<---------| (Client) | |____________| |____________|--------->|____________| Figure 4: CoAP Publish-Subscribe A broker might be implemented as a data hub by creating the topics as resources on the data hub server and linking to these from the data hub resource with the "item" link relation type (Figure 5). Hypermedia controls in the data hub representation enable publishers to create, update and delete topics, and subscribers to read/observe these topics. +------------------------------+ | ___ | | / \ Data Hub | | \___/ ___ | | |__________/ \ Topic A | | | item \___/ | | | ___ | | |__________/ \ Topic B | | | item \___/ | | | ___ | | |__________/ \ Topic C | | item \___/ | | | +------------------------------+ Figure 5: A Data Hub Acting as a Publish-Subscribe Broker +-------------+------------------+ | Interaction | Mapped to | +-------------+------------------+ | DISCOVER | Discovery / | | | Read Data Hub / | | | Find Items | | CREATE | Create Item | | PUBLISH | Update Item | | SUBSCRIBE | Observe Item | | UNSUBSCRIBE | Observe Item | | READ | Read Item | | REMOVE | Delete Item | +-------------+------------------+ Table 1: Mapping of Pub/Sub Interactions to Data Hub Hartke Expires May 17, 2017 [Page 11] Internet-Draft Thing-to-Thing Data Hub November 2016 A.3. CoRE Resource Directory A CoRE Resource Directory [I-D.ietf-core-resource-directory] hosts descriptions of resources held on other servers, allowing lookups to be performed for those descriptions. The descriptions are encoded as links in CoRE Link Format [RFC6690] that are annotated with a variety of link attributes providing the type of and hints about the linked resources. +----------------------------------+ | ___ | | / \ Data Hub | | \___/ ___ | | |__________/ \ Link Format | +------------------------+ | | item \___/ Resource | | ___ | | | |________________|____|__/ \ Resource A | | | hosts | | \___/ | | | | | | | | ___ | +------------------------+ | |__________/ \ Link Format | +------------------------+ | item \___/ Resource | | ___ | | |________________|____|__/ \ Resource B | | hosts | | \___/ | | | | | +----------------------------------+ +------------------------+ Figure 6: A Data Hub Storing Links A data hub might store these resource descriptions such that each resource description becomes one item in the data hub and each item links to the respective resource (Figure 6). +-----------------------+-------------+ | Interaction | Mapped to | +-----------------------+-------------+ | Discovery | Discovery | | Registration | Create Item | | Update | Update Item | | Removal | Delete Item | | Read Endpoint Links | - | | Update Endpoint Links | - | | Register a Group | - | | Group Removal | - | | Lookup | Find Items | +-----------------------+-------------+ Table 2: Mapping of Resource Directory Interactions to Data Hub Hartke Expires May 17, 2017 [Page 12] Internet-Draft Thing-to-Thing Data Hub November 2016 A.4. CoRE Mirror Server Similar to a CoAP Publish-Subscribe Broker, a CoRE Mirror Server [I-D.vial-core-mirror-server] allows a sleepy device to store representations of their resources so that other devices can access the representations while it is sleeping. +----------------------------------+ | ___ | | / \ Data Hub | | \___/ ___ | | |___________/ \ Mirrored | | | item \___/ Resource A | | | ___ | | |___________/ \ Mirrored | | | item \___/ Resource B | | | ___ | | |___________/ \ Mirrored | | item \___/ Resource C | | | +----------------------------------+ Figure 7: A Data Hub Acting as a Mirror Server +----------------------------+-------------+ | Interaction | Mapped to | +----------------------------+-------------+ | Discovery | Discovery | | Registration | Create Item | | Removal | Delete Item | | Update Mirrored Resource | Update Item | | Retrieve Mirrored Resource | Read Item | +----------------------------+-------------+ Table 3: Mapping of Mirror Server Interactions to Data Hub Author's Address Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63905 Email: hartke@tzi.org Hartke Expires May 17, 2017 [Page 13]