CoRE Working Group JH. Choi Internet-Draft Samsung Intended status: Standards Track G. Bajko Expires: January 7, 2016 MediaTek D. Thakore CableLabs July 6, 2015 Resource Model Indication with CoAP draft-jinchoe-resource-model-indication-00 Abstract There is much interest in "Internet of Things (IoT)" and multiple standards following the REST architectural style are under development. In a RESTful interaction, IoT devices need to understand each other's resource representations, both the semantic meaning and the syntactic form, to interact properly. For interoperability among different standards, it is helpful for CoAP endpoints to indicate the resource models they support. This document presents a scheme for IoT devices to exchange their resource model information and requests from IANA new Internet media types and CoAP Content-Format identifier for resource model indication. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Choi, et al. Expires January 7, 2016 [Page 1] Internet-Draft Resource Model Indication with CoAP July 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. IoT trend . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. REST and interoperability . . . . . . . . . . . . . . . . 3 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Resource model indication . . . . . . . . . . . . . . . . . . 4 2.1. Different resource models . . . . . . . . . . . . . . . . 4 2.2. A scheme to exchange resource model information . . . . . 6 2.3. Content-Format request for OIC resource model . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.1. New Internet media type - application/vnd.oic . . . . . . 7 3.2. New Internet media type: application/vnd.oic+json . . . . 8 3.3. New Internet media type: application/vnd.oic+cbor . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1. IoT trend The term "Internet of Things (IoT)" denotes a trend where a large number of devices, i.e sensors and actuators, are embedded in physical world and networked by Internet protocols to provide services such as smart home or connected health. Users can access the networked devices to acquire the real world information (e.g. monitoring heartbeat rate) and control the physical environments (e.g. adjusting room temperature). IoT gains traction among academia, industry and government circles for its business potential and social impact. Cisco promotes the "Internet of Everything (IoE)", the networked connection of people, process, data, and things [IoE], GE initiates "Industrial Internet", the integration of complex physical machinery with networked sensors and software, to organize the Industrial Internet Consortium [IIC]. Choi, et al. Expires January 7, 2016 [Page 2] Internet-Draft Resource Model Indication with CoAP July 2015 IoT requires standardization for interoperability among diverse devices and multiple standards are under development currently. IETF defines network and web transfer protocol (e.g. 6lowpan [RFC6775] and CoAP [RFC6690], [RFC7252]), oneM2M [oneM2M] produces technical specifications for a common M2M Service Layer [oneM2M-TS0001], [oneM2M-TS0004], IPSO Alliance [IPSO] publishes Smart Object Guideline [IPSOSmartObjects] and "Open Interconnect Consortium (OIC)" constructs standards and certification for IoT devices [OIC]. 1.2. REST and interoperability Multitude of IoT standards are based on "Representational State Transfer (REST)", which is a software architecture style with a coordinated set of constraints for the design of components in a distributed hypermedia system [REST]. In REST based IoT, a real world entity is represented as resource in a server, which a client accesses and manipulates through RESTful actions on its representation to interact with the entity, i.e. sensing and controlling the physical environments. Moreover several IoT standards adopt the common network and web transfer protocols. oneM2M, IPSO and OIC all use CoAP and IP/ UDP, [oneM2M-TS0008], [IPSO], [OIC] so any client and server supporting those standards can exchange request and response messages. However in order to interact properly, it's not sufficient for IoT devices to simply transfer CoAP messages. IoT devices should understand each other's resources and be aware of their semantic meaning and syntactic form. Currently each standard defines its own "resource model" and specifies a different scheme to construct resources from physical entities such as light [OIC], [IPSOFramework], [IPSOSmartObjects], [oneM2M-TS0001]. Hence client and server adopting different standards can't perform meaningful interaction, i.e. the client can't manipulate the resource representation in the server. For wider interoperability among multiple standards, IoT devices need to understand each other's resource model to process CoAP request and response message properly. To interpret resources correctly, clients and servers need to determine which resource model they support in the first place. The client should be aware of whether its corresponding server adopts oneM2M or OIC model and vice versa. It is also possible for a server to support multiple resource models for the same resource. CoAP provides a scheme to notify the Content-Format information which CoAP endpoints, i.e. client or server, support. A client can use the CoAP Accept Option to inform a server which Content-Format is acceptable and the server returns the preferred Content-Format if Choi, et al. Expires January 7, 2016 [Page 3] Internet-Draft Resource Model Indication with CoAP July 2015 available. The Content-Format Option in a response message indicates the representation format of the payload [RFC7252]. With a similar approach this document presents a way for CoAP endpoints to exchange the resource model information among each other. Also this document requests from IANA new Internet media types and numeric Content-Format identifier indicating resource model for OIC (e.g. application/vnd.oic+json). 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Resource model indication 2.1. Different resource models In REST based IoT, a physical or software artefact or concept that needs to be made visible and manipulated is represented as resource. The resource encapsulates and presents the salient aspect of an entity with attributes or properties. For example, the notable feature of a smart light can be represented as "light control" resource with the attributes of "On/off", exposing the power state of the light and "Dimmer", the brightness. A scheme to construct resource from entity is denoted as "resource model", "data model" or "application profile". Take notice that there is no consensus on terminology, so the terms "resource", "resource type", "attribute" and "property" convey different meanings in different organizations. Currently several standard bodies or Industrial alliances such as oneM2M, IPSO, OIC specifies resource model in different ways. For example, a smart light can be represented as an IPSO Smart Object in JSON as below: Choi, et al. Expires January 7, 2016 [Page 4] Internet-Draft Resource Model Indication with CoAP July 2015 { "3311": { "description": "IPSO light control", "instances": { "0": { "resources": { "5850": { "description": "On/Off", "value": 0 }, "5851": { "description": "Dimmer", "value": 70 } } } } } } In the above, "3311" is an "Object ID" defining object type, "0" an "Object Instance", designating one or more instances, "5850", "5851", "Resource ID", defining resource type. Also IPSO embeds resource information in data path so "On/Off" resource has predetermined data path of "3311/0/5850" and "Dimmer" resource datapath of "3311/0/5851" [IPSOSmartObjects]. Whereas other SDOs (e.g. oneM2M or OIC) adopt opaque datapaths and separate attributes to indicate resource type (object type in IPSO terminology) [oneM2M-TS0001], [RFC6690]. Under this framework, a smart light may be represented in JSON as below: { "rt": "oic.r.lt", "on": { "description": "On/Off", "value": 0 }, "dim": { "description": "Dimmer", "value": 70 } } Choi, et al. Expires January 7, 2016 [Page 5] Internet-Draft Resource Model Indication with CoAP July 2015 Note that the same salient features of a smart light, power on/off and brightness, are turned into two different resources (or resource endpoints). 2.2. A scheme to exchange resource model information IoT devices, i.e. clients and servers, need to understand the resource model that the corresponding device supports in order to interoperate. For the initial step, it would help for IoT devices to indicate the resource model(s) that each device supports. Then clients and servers may choose a common resource model for interaction, or in the absence of such a common model, rely on translation between the models, possibly with the assistance of 3rd party intermediary. This document presents a scheme for CoAP endpoints, clients and servers, to negotiate the resource model they support. First, the Internet media type and Content-Format identifier are used to indicate a specific resource model. The Internet media types can be defined to indicate the resource models, potentially with content- coding, such as "application/ipso+json", then assigned numeric Content-Format identifiers such as "123123" to minimize payload overhead for CoAP usage. Second, CoAP Accept and Content-Format Option are used to exchange the Content-Format identifiers indicating the resource models which CoAP endpoints prefer or support. A client includes the CoAP Accept option to inform a server which resource model(s), potentially with content-encoding, are acceptable and the server returns the payload in the preferred resource model if supported. The Content-Format Option indicates the resource model of the payload. 2.3. Content-Format request for OIC resource model The Open Interconnect Consortium (OIC) is an industry group with the objective of specifying standards and certification for devices involved in the Internet of Things based around CoAP [OIC]. OIC is currently developing resource models for IoT services (e.g. smart home) and strives to align with other standard bodies such as oneM2M/IPSO, so that OIC devices can interoperate with devices following different standards. This document proposes a scheme to exchange resource model information as describes in the previous sections. Choi, et al. Expires January 7, 2016 [Page 6] Internet-Draft Resource Model Indication with CoAP July 2015 The resource mode indication scheme requires new Internet media types and CoAP Content-Format identifiers which can indicate OIC resource models with content encoding. Hence the following new Internet media types are requested from IANA: o application/vnd.oic o application/vnd.oic+json o applicatoin/vnd.oic+cbor 3. IANA Considerations 3.1. New Internet media type - application/vnd.oic This specification registers a new Internet media type for OIC resource model, "application/vnd.oic". Type name: application Subtype name: vnd.oic Required parameters: None Optional parameters: None Encoding considerations: None Security considerations: As defined in this specification Interoperability considerations: None Published specification: This specification. Applications that use this media type: Any device supporting the OIC resource models Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): Personal & email address to contact for further information: JinHyeock Choi Choi, et al. Expires January 7, 2016 [Page 7] Internet-Draft Resource Model Indication with CoAP July 2015 Intended usage: COMMON Authors: TBD Change controller: IETF 3.2. New Internet media type: application/vnd.oic+json This specification registers a new Internet media type for OIC resource model, "application/vnd.oic+json". Type name: application Subtype name: vnd.oic+json Required parameters: None Optional parameters: None Encoding considerations: JSON Security considerations: As defined in this specification Interoperability considerations: None Published specification: This specification. Applications that use this media type: Any device supporting the OIC resource models Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): Personal & email address to contact for further information: JinHyeock Choi Authors: TBD Intended usage: COMMON Change controller: IETF Choi, et al. Expires January 7, 2016 [Page 8] Internet-Draft Resource Model Indication with CoAP July 2015 3.3. New Internet media type: application/vnd.oic+cbor This specification registers a new Internet media type for OIC resource model, "application/vnd.oic+cbor". Type name: application Subtype name: vnd.oic+cbor Required parameters: None Optional parameters: None Encoding considerations: CBOR Security considerations: As defined in this specification Interoperability considerations: None Published specification: This specification. Applications that use this media type: Any device supporting the OIC resource models Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): Personal & email address to contact for further information: JinHyeock Choi Authors: TBD Intended usage: COMMON Change controller: IETF 4. Security Considerations TBD Choi, et al. Expires January 7, 2016 [Page 9] Internet-Draft Resource Model Indication with CoAP July 2015 5. Acknowledgements This document results from OIC specification discussion. Ravi Subramaniam provided valuable feedback from the beginning and we are grateful to the other members for their contribution. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. 6.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012. [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, October 2013. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. Choi, et al. Expires January 7, 2016 [Page 10] Internet-Draft Resource Model Indication with CoAP July 2015 [I-D.ietf-core-links-json] Bormann, C., "Representing CoRE Link Collections in JSON", draft-ietf-core-links-json-02 (work in progress), July 2014. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, . [IPSO] "IPSO Alliance Home Page", . [IPSOFramework] Shelby, Z. and C. Chauvenet, "The IPSO Application Framework", August 2012, . [IPSOSmartObjects] "IPSO SmartObject Guideline", September 2014, . [OIC] "Open Interconnect Consortium (OIC) Home Page", . [oneM2M] "oneM2M Home Page", . [oneM2M-TS0001] "Functional Architecture", January 2015, . [oneM2M-TS0004] "Service Layer Core Protocol Specification", January 2015, . [oneM2M-TS0008] "CoAP Protocol Binding", January 2015, . [IIC] "Industrial Internet Consortium (IIC) Home Page", . [IoE] "Internet of Everything (IoE) Home Page", . Choi, et al. Expires January 7, 2016 [Page 11] Internet-Draft Resource Model Indication with CoAP July 2015 Authors' Addresses JinHyeock Choi Samsung Electronics Co., Ltd. 129 Samsung-ro Suwon, Gyeonggi 443-742 Korea Email: jinchoe@samsung.com Gabor Bajko MediaTek USA Inc. 2860 Junction Ave San Jose, CA 95134 USA Email: gabor.bajko@mediatek.com D. Thakore Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80023 USA Email: d.thakore@cablelabs.com Choi, et al. Expires January 7, 2016 [Page 12]