Thing-to-Thing Research Group K. Hartke Internet-Draft Universitaet Bremen TZI Intended status: Experimental October 30, 2016 Expires: May 3, 2017 Thing-to-Thing Bulletin Board draft-hartke-t2trg-bulletin-board-01 Abstract A Thing-to-Thing Bulletin Board is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communication to publish 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 3, 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 3, 2017 [Page 1] Internet-Draft Thing-to-Thing Bulletin Board October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Bulletin Boards . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 3 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. Proof-of-Concept . . . . . . . . . . . . . . . . . . 8 A.1. CoRE Lighting . . . . . . . . . . . . . . . . . . . . . . 8 A.2. CoAP Publish-Subscribe . . . . . . . . . . . . . . . . . 10 A.3. CoRE Resource Directory . . . . . . . . . . . . . . . . . 11 A.4. CoRE Mirror Server . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction CoRE Lighting [I-D.hartke-core-lighting] defines a "bulletin board" application that can be used to share the thing descriptions of sensor and actuator nodes. This document generalizes the bulletin board concept to support representations in any media type and defines means for creating, reading, observing, updating, deleting and finding items in a bulletin board. The generalization to any media type provides two advantages. The first is media type agility: applications won't be stuck forever with the media types of CoRE Lighting. The second is that it may be useful to share also other information than thing descriptions, such as default configurations for new devices, service locations or sleep schedules. Finding items by submitting a search query allows clients to retrieve a subset of items from a bulletin board. In CoRE Lighting, a client has to download the whole set of thing descriptions, filter the set and configure compatible devices. It may be more efficient to filter the set at the bulletin board 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. The generalized bulletin board is presented as a CoRE Application Description [I-D.hartke-core-apps]. That is, the focus of the Hartke Expires May 3, 2017 [Page 2] Internet-Draft Thing-to-Thing Bulletin Board October 2016 application interface is on the media types used in the bulletin board application and interactions are driven by links and forms. 1.1. Related Work The bulletin board is an instance of the well-known REST collection pattern. As such, it might be used in places where a more specific instance of the collection pattern is currently used, such as the Publish-Subscribe Broker [I-D.ietf-core-coap-pubsub] or the CoRE Resource Directory [I-D.ietf-core-resource-directory]. Appendix A explores this direction and provides a proof-of-concept mapping from publish-subscribe broker and resource directory to bulletin boards. The key differentiator of the bulletin board compared to publish- subscribe broker and resource directory lies in the evolvability, the ability to respond effectively to change (such as the introduction of new features) without negatively impacting existing and new clients. The definition of 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 bulletin board facilitates fine-grained evolvability by driving all interactions through machine-understandable hypertext. Features can be added, changed or removed in a backwards-compatible way simply by updating the bulletin board to expose corresponding links and forms. 1.2. 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. Bulletin Boards This section defines the data model and the interaction model of bulletin boards. 2.1. Data Model The data model consists of two elements: the bulletin board and a number of published items (Figure 1). Hartke Expires May 3, 2017 [Page 3] Internet-Draft Thing-to-Thing Bulletin Board October 2016 ___ Bulletin / \ Board \___/ ___ |__________/ \ Item 1 | item \___/ | ___ |__________/ \ Item 2 | item \___/ | . | . | . | ___ |__________/ \ Item N item \___/ Figure 1: A Bulletin Board with a Number of Published Items Bulletin Board A bulletin board is a Web application intended for the posting of public messages, for example, to share thing descriptions, announce services or provide information. Sensor and actuator nodes can leave and erase messages for other nodes to read and see. A bulletin board resource is a collection of published items. Its representation consists primarily of links to the item resources using the "item" link relation type [RFC6573]. To reduce the number of round-trips, it can also embed (complete or partial) representations of those item resources. Forms contained in the representation enable interactions with the bulletin board. For a start, a bulletin board has only a depth of one level; i.e., all published items are organized directly under the bulletin board resource. This could be extended to multiple levels in a future revision of this draft. Bulletin board representations are formatted in the "application/ coral" media type [I-D.hartke-t2trg-coral]. Item A bulletin board item is a member of the collection. Item representations can in principle be formatted in any media type; a bulletin board deployment MAY restrict the media types it accepts for publication, though. Hartke Expires May 3, 2017 [Page 4] Internet-Draft Thing-to-Thing Bulletin Board October 2016 The representations of items MAY link back to a bulletin board resource using the "collection" link relation type [RFC6573]. 2.2. Interaction Model The interaction model consists of eight possible interactions with a bulletin board: discovering and reading the bulletin board, and creating, reading, observing, updating, deleting and finding published items in the bulletin board. Discovery For a start, nodes are assumed to be pre-configured out-of-band with a link to a bulletin board. Read Bulletin Board A node can retrieve a representation of the bulletin board by following the discovered link. The representation of the bulletin board includes links to and/or literals with representations of the items in the bulletin board. The representation MAY also include forms for creating, updating, deleting and finding items. Create Item The representation of a bulletin board 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 bulletin board. 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 bulletin board. 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 bulletin board and observing the resource as specified in [RFC7641]. Update Item For each item in a bulletin board, the representation of the bulletin board 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 Hartke Expires May 3, 2017 [Page 5] Internet-Draft Thing-to-Thing Bulletin Board October 2016 relation type. Submitting this form updates the item in the bulletin board to the submitted representation. Delete Item For each item in a bulletin board, the representation of the bulletin board 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 bulletin board. 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 bulletin board that matches the filter. (The details of this are TBD.) 2.3. Application Description Application name: Thing-to-Thing Bulletin Board 1.0 URI schemes: coap [RFC7252] Media types: application/coral [I-D.hartke-t2trg-coral] 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. Hartke Expires May 3, 2017 [Page 6] Internet-Draft Thing-to-Thing Bulletin Board October 2016 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. [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, . Hartke Expires May 3, 2017 [Page 7] Internet-Draft Thing-to-Thing Bulletin Board October 2016 [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-08 (work in progress), July 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, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . Appendix A. Proof-of-Concept There are a number of specifications (CoRE Lighting, CoAP Publish- Subscribe Broker, CoRE Resource Directory and CoRE Mirror Server) that implement variations of the collection pattern. This section shows how they might be implemented using a bulletin board (without trying to replicate them in full 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- Hartke Expires May 3, 2017 [Page 8] Internet-Draft Thing-to-Thing Bulletin Board October 2016 readable information and machine-understandable hypermedia controls which indicate the possible interactions with the thing. +----------------------------------+ | ___ | | / \ Bulletin Board | | \___/ ___ | | |__________/ \ Thing | +------------------------+ | | item \___/ Description | | ___ | | | |________________|____|__/ \ Light Bulb | | | config | | \___/ Configuration | | | | | | | | ___ | +------------------------+ | |__________/ \ Thing | +------------------------+ | item \___/ Description | | ___ | | |________________|____|__/ \ Light Remote | | about | | \___/ Control State | | | | | +----------------------------------+ +------------------------+ Figure 2: A Bulletin Board Storing Thing Descriptions Matching the example in Section 5.2.1 of [I-D.hartke-core-lighting], Figure 2 shows a bulletin board with two thing descriptions. The first 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 bulletin board representation thus could look as shown in Figure 3. Hartke Expires May 3, 2017 [Page 9] Internet-Draft Thing-to-Thing Bulletin Board October 2016 ______________________________ | | | 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 Bulletin Board 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). ____________ ____________ ____________ | |--------->| | | | | Publisher |<---------| Broker | | Subscriber | | (Client) | | (Server) |<---------| (Client) | |____________| |____________|--------->|____________| Figure 4: CoAP Publish-Subscribe A broker might be implemented as a bulletin board by creating the topics as resources on the bulletin board server and linking to these from the bulletin board resource with the "item" link relation type Hartke Expires May 3, 2017 [Page 10] Internet-Draft Thing-to-Thing Bulletin Board October 2016 (Figure 5). Hypermedia controls in the bulletin board representation enable publishers to create, update and delete topics, and subscribers to read/observe these topics. +------------------------------+ | ___ | | / \ Bulletin Board | | \___/ ___ | | |__________/ \ Topic A | | | item \___/ | | | ___ | | |__________/ \ Topic B | | | item \___/ | | | ___ | | |__________/ \ Topic C | | item \___/ | | | +------------------------------+ Figure 5: A Bulletin Board Acting as a Publish-Subscribe Broker +-------------+------------------------+ | Interaction | Mapped to | +-------------+------------------------+ | DISCOVER | Discovery / | | | Read Bulletin Board / | | | 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 Bulletin Board 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 resources. 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. Hartke Expires May 3, 2017 [Page 11] Internet-Draft Thing-to-Thing Bulletin Board October 2016 +----------------------------------+ | ___ | | / \ Bulletin Board | | \___/ ___ | | |__________/ \ Link Format | +------------------------+ | | item \___/ Resource | | ___ | | | |________________|____|__/ \ Resource A | | | hosts | | \___/ | | | | | | | | ___ | +------------------------+ | |__________/ \ Link Format | +------------------------+ | item \___/ Resource | | ___ | | |________________|____|__/ \ Resource B | | hosts | | \___/ | | | | | +----------------------------------+ +------------------------+ Figure 6: A Bulletin Board Storing Links A bulletin board might store these resource descriptions such that each resource description becomes one item in the bulletin board 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 Bulletin Board 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. Hartke Expires May 3, 2017 [Page 12] Internet-Draft Thing-to-Thing Bulletin Board October 2016 +----------------------------------+ | ___ | | / \ Bulletin Board | | \___/ ___ | | |___________/ \ Mirrored | | | item \___/ Resource A | | | ___ | | |___________/ \ Mirrored | | | item \___/ Resource B | | | ___ | | |___________/ \ Mirrored | | item \___/ Resource C | | | +----------------------------------+ Figure 7: A Bulletin Board 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 Bulletin Board 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 3, 2017 [Page 13]