idnits 2.17.1 draft-ietf-core-interfaces-06.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6690]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-14) exists of draft-ietf-core-dynlink-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-08 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-03 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group Z. Shelby 3 Internet-Draft ARM 4 Intended status: Informational Z. Vial 5 Expires: May 1, 2017 Schneider-Electric 6 M. Koster 7 SmartThings 8 C. Groves 9 Huawei 10 October 28, 2016 12 Reusable Interface Definitions for Constrained RESTful Environments 13 draft-ietf-core-interfaces-06 15 Abstract 17 This document defines a set of Constrained RESTful Environments 18 (CoRE) Link Format Interface Descriptions [RFC6690] applicable for 19 use in constrained environments. These include the: Actuator, 20 Paramter, Read-only parameter, Sensor, Batch, Linked Batch and Link 21 List interfaces. 23 The Batch, Linked Batch and Link List interfaces make use of resource 24 collections. This document further describes how collections relate 25 to interfaces. 27 Many applications require a set of interface descriptions in order 28 provide the required functionality. This document defines the 29 concept of function sets to specify this set of interfaces and 30 resources. 32 _Editor's note: The git repository for the draft is found at 33 https://github.com/core-wg/interfaces_ 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 1, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Collections . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Introduction to Collections . . . . . . . . . . . . . . . 5 72 3.2. Use Cases for Collections . . . . . . . . . . . . . . . . 6 73 3.3. Content-Formats for Collections . . . . . . . . . . . . . 6 74 3.4. Links and Items in Collections . . . . . . . . . . . . . 7 75 3.5. Queries on Collections . . . . . . . . . . . . . . . . . 8 76 3.6. Observing Collections . . . . . . . . . . . . . . . . . . 8 77 3.7. Collection Types . . . . . . . . . . . . . . . . . . . . 9 78 4. Interface Descriptions . . . . . . . . . . . . . . . . . . . 9 79 4.1. Link List . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.2. Batch . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.3. Linked Batch . . . . . . . . . . . . . . . . . . . . . . 12 82 4.4. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.5. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.6. Read-only Parameter . . . . . . . . . . . . . . . . . . . 14 85 4.7. Actuator . . . . . . . . . . . . . . . . . . . . . . . . 14 86 5. Function Sets and Profiles . . . . . . . . . . . . . . . . . 15 87 5.1. Defining a Function Set . . . . . . . . . . . . . . . . . 16 88 5.1.1. Path template . . . . . . . . . . . . . . . . . . . . 16 89 5.1.2. Resource Type . . . . . . . . . . . . . . . . . . . . 16 90 5.1.3. Interface Description . . . . . . . . . . . . . . . . 17 91 5.1.4. Data type . . . . . . . . . . . . . . . . . . . . . . 17 92 5.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.3. Versioning . . . . . . . . . . . . . . . . . . . . . . . 17 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 7.1. Link List . . . . . . . . . . . . . . . . . . . . . . . . 18 97 7.2. Batch . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 7.3. Linked Batch . . . . . . . . . . . . . . . . . . . . . . 18 99 7.4. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 7.5. Parameter . . . . . . . . . . . . . . . . . . . . . . . . 19 101 7.6. Read-only parameter . . . . . . . . . . . . . . . . . . . 19 102 7.7. Actuator . . . . . . . . . . . . . . . . . . . . . . . . 19 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 104 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 107 10.2. Informative References . . . . . . . . . . . . . . . . . 23 108 Appendix A. Current Usage of Interfaces and Function Sets . . . 24 109 A.1. Constrained RESTful Environments (CoRE) Link Format 110 (IETF) . . . . . . . . . . . . . . . . . . . . . . . . . 25 111 A.2. CoRE Resource Directory (IETF) . . . . . . . . . . . . . 25 112 A.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 25 113 A.4. oneM2M . . . . . . . . . . . . . . . . . . . . . . . . . 26 114 A.5. OMA LWM2M . . . . . . . . . . . . . . . . . . . . . . . . 26 115 Appendix B. Profile example . . . . . . . . . . . . . . . . . . 27 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 118 1. Introduction 120 IETF Standards for machine to machine communication in constrained 121 environments describe a REST protocol and a set of related 122 information standards that may be used to represent machine data and 123 machine metadata in REST interfaces. CoRE Link-format is a standard 124 for doing Web Linking [RFC5988] in constrained environments. SenML 125 [I-D.ietf-core-senml] is a simple data model and representation 126 format for composite and complex structured resources. CoRE Link- 127 Format and SenML can be used by CoAP [RFC7252] or HTTP servers. 129 The discovery of resources offered by a constrained server is very 130 important in machine-to-machine applications where there are no 131 humans in the loop. Machine application clients must be able to 132 adapt to different resource organizations without advance knowledge 133 of the specific data structures hosted by each connected thing. The 134 use of Web Linking for the description and discovery of resources 135 hosted by constrained web servers is specified by CoRE Link Format 136 [RFC6690]. CoRE Link Format additionally defines a link attribute 137 for interface description ("if") that can be used to describe the 138 REST interface of a resource, and may include a link to a description 139 document. 141 This document defines a set of Link Format interface descriptions for 142 some common design patterns that enable the server side composition 143 and organization, and client side discovery and consumption, of 144 machine resources using Web Linking. A client discovering the "if" 145 link attribute will be able to consume resources based on its 146 knowledge of the expected interface types. In this sense the 147 Interface Type acts in a similar way as a Content-Format, but as a 148 selector for a high level functional abstraction. 150 An interface description describes a resource in terms of it's 151 associated content formats, data types, URI templates, REST methods, 152 parameters, and responses. Basic interface descriptions are defined 153 for sensors, actuators, and properties. 155 A set of collection types is defined for organizing resources for 156 discovery, and for various forms of bulk interaction with resource 157 sets using typed embedding links. 159 Interface descriptions may be used in the composition of Function 160 Sets and Profiles. Function Sets and Profiles are described and an 161 example is given of a sensor and actuator device profile using 162 Function Sets composed from the interface descriptions described in 163 this document. 165 This document first defines the concept of collection interface 166 descriptions. It then defines a number of generic interface 167 descriptions that may be used in contrained environments. Several of 168 these interface descriptions utilise collections. The interface 169 descriptions are then used by the function sets. 171 Whilst this document assumes the use of CoAP [RFC7252], the REST 172 interfaces described can also be realized using HTTP [RFC7230]. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in 179 [RFC2119]. 181 This document requires readers to be familiar with all the terms and 182 concepts that are discussed in [RFC5988] and [RFC6690]. This 183 document makes use of the following additional terminology: 185 Device: An IP smart object running a web server that hosts a group 186 of Function Set instances from a profile. 188 Function Set: A group of well-known REST resources that provides a 189 particular service. 191 Gradual Reveal: A REST design where resources are discovered 192 progressively using Web Linking. 194 Interface Description: The Interface Description describes the 195 generic REST interface to interact with a resource or a set of 196 resources. Its use is described via the Interface Description 197 'if' attribute which is an opaque string used to provide a name or 198 URI indicating a specific interface definition used to interact 199 with the target resource. One can think of this as describing 200 verbs usable on a resource. 202 Profile: A group of well-known Function Sets defined by a 203 specification. 205 Resource Discovery: The process allowing a web client to identify 206 resources being hosted on a web server. 208 Service Discovery: The process making it possible for a web client 209 to automatically detect devices and Function Sets offered by these 210 devices on a CoRE network. 212 3. Collections 214 3.1. Introduction to Collections 216 A Collection is a resource which represents one or more related 217 resources. [RFC6573] describes the "item" and "collection" Link 218 Relation. "item" link relation identifies a member of collection. 219 "collection" indicates the collection that an item is a member of. 220 For example: A collection might be a resource representing catalog of 221 products, an item is a resource related to an individual product. 223 Section 1.2.2/[RFC6690] also describes resource collections. 225 This document uses the concept of "collection" and applies it to 226 interface descriptions. A collection interface description consists 227 of a set of links and a set of items pointed to by the links which 228 may be sub-resources of the collection resource. The collection 229 interface descriptions described in this document are Link List, 230 Batch and Linked Batch. 232 The links in a collection are represented in CoRE Link-Format 233 Content-Formats including JSON and CBOR variants, and the items in 234 the collection may be represented by senml, including JSON and CBOR 235 variants. In general, a collection may support items of any 236 available Content-Format. 238 A particular resource item may be a member of more than one 239 collection at a time by being linked to, but may only be a 240 subresource of one collection. 242 Some collections may have pre-configured items and links, and some 243 collections may support dynamic creation and removal of items and 244 links. Likewise, modification of items in some collections may be 245 permitted, and not in others. 247 Collections may support link embedding, which is analogous to an 248 image tag (link) causing the image to display inline in a browser 249 window. Resources pointed to by embedded links in collections may be 250 interacted with using bulk operations on the collection resource. 251 For example, performing a GET on a collection resource may return a 252 single representation containing all of the linked resources. 254 Links in collections may be selected for processing by a particular 255 request by using Query Filtering as described in CoRE Link-Format 256 [RFC6690]. 258 3.2. Use Cases for Collections 260 Collections may be used to provide gradual reveal of resources on an 261 endpoint. There may be a small set of links at the .well-known/core 262 location, which may in turn point to other collections of resources 263 that represent device information, device configuration, device 264 management, and various functional clusters of resources on the 265 device. 267 A collection may provide resource encapsulation, where link embedding 268 may be used to provide a single resource with which a client may 269 interact to obtain a set of related resource values. For example, a 270 collection for manufacturer parameters may consist of manufacturer 271 name, date of manufacture, location of manufacture, and serial number 272 resources which can be read as a single senml data object. 274 A collection may be used to group a set of like resources for bulk 275 state update or actuation. For example, the brightness control 276 resources of a number of luminaries may be grouped by linking to them 277 in a collection. The collection type may support receiving a single 278 update form a client and sending that update to each resource item in 279 the collection. 281 Items may be sub-resources of the collection resource. This enables 282 updates to multiple items in the collection to be processed together 283 within the context of the collection resource. 285 3.3. Content-Formats for Collections 287 The collection interfaces by default use CoRE Link-Format for the 288 link representations and SenML or text/plain for representations of 289 items. The examples given are for collections that expose resources 290 and links in these formats. In addition, a new "collection" Content- 291 Format is defined based on the SenML framework which represents both 292 links and items in the collection. 294 The choice of whether to return a representation of the links or of 295 the items or of the collection format is determined by the accepts 296 header option in the request. Likewise, the choice of updating link 297 metadata or item data or the collection resource itself is determined 298 by the Content-Format option in the header of the update request 299 operation. 301 The default Content-Formats for collection types described in this 302 document are: 304 Links: application/link-format, application/link-format+json 306 Items: application/senml+json, text/plain 308 3.4. Links and Items in Collections 310 Links use CoRE Link-Format representation by default and may point to 311 any resource reachable from the context of the collection. This 312 includes absolute links and links that point to other network 313 locations if the context of the collection allows. Links to sub- 314 resources in the collection MUST have a path-element starting with 315 the resource name, as per [RFC3986]. Links to resources in the 316 global context MUST start with a root path identifier [RFC5988]. 317 Links to other collections are formed per [RFC3986]. 319 Examples of links: 321 ;if="core.lb"': Link to the /sen/ collection describing it as 322 a core.lb type collection (Linked Batch) 324 ;rel="grp"': Link to the /sen/ collection indicating that 325 /sen/ is a member of a group in the collection in which the link 326 appears. 328 <"/sen/temp">;rt="temperature"': An absolute link to the resource at 329 the path /sen/temp 331 ;rt="temperature": Link to the temp subresource of the 332 collection in which this link appears." 334 ;anchor="/sen/": A link to the temp subresource of the 335 collection /sen/ which is assumed not to be a subresource of the 336 collection in which the link appears ,but is expected to be 337 identified in the collection by resource name. 339 Links in the collection MAY be Read, Updated, Added, or Removed using 340 the CoRE Link-Format or JSON Merge-Patch Content-Formats on the 341 collection resource. Reading links uses the GET method and returns 342 an array or list containing the link-values of all selected links. 343 Links may be added to the collection using POST or PATCH methods. 344 Updates to links MUST use the PATCH method and MAY use query 345 filtering to select links for updating. The PATCH method on links 346 MUST use the JSON Merge-Patch Content-Format (application/merge- 347 patch+json) specified in [RFC7396]. 349 Items in the collection SHOULD be represented using the SenML 350 (application/senml+json) or plain text (text/plain) Content-Formats, 351 depending on whether the representation is of a single data point or 352 multiple data points. Items MAY be represented using any supported 353 Content-Format. 355 Link Embedding enables the bulk processing of items in the collection 356 using a single operation targeting the collection resource. A subset 357 of resources in the collection may be selected for operation using 358 Query Filtering. Bulk Read operations using GET return a SenML 359 representation of all selected resources. Bulk item Update 360 operations using PUT or POST apply the payload document to all 361 selected resource items in the collection, using either a Batch or 362 Group update policy. A Batch update is performed by applying the 363 resource values in the payload document to all resources in the 364 collection that match any resource name in the payload document. 365 Group updates are performed by applying the payload document to each 366 item in the collection. Group updates are indicated by the link 367 relation type rel="grp" in the link. 369 3.5. Queries on Collections 371 Collections MAY support query filtering as defined in CoRE Link- 372 Format [RFC6690]. Operations targeting either the links or the items 373 MAY select a subset of links and items in the collection by using 374 query filtering. The Content-Format specified in the request header 375 selects whether links or items are targeted by the operation. 377 3.6. Observing Collections 379 Resource Observation via [I-D.ietf-core-dynlink] using CoAP [RFC7252] 380 MAY be supported on items in a collection. A subset of the 381 conditional observe parameters MAY be specified to apply. In most 382 cases pmin and pmax are useful. Resource observation on a 383 collection's items resource MAY report any changes of resource state 384 in any item in the collection. Observation Responses, or 385 notifications, SHOULD provide representations of the resources that 386 have changed in SenML Content-Format. Notifications MAY include 387 multiple observations of a particular resource, with SenML time 388 stamps indicating the observation times. 390 3.7. Collection Types 392 There are three collection types defined in this document: 394 +-----------------+---------+--------------------+ 395 | Collection Type | if= | Content-Format | 396 +-----------------+---------+--------------------+ 397 | Link List | core.ll | link-format | 398 | | | | 399 | Batch | core.b | link-format, senml | 400 | | | | 401 | Linked Batch | core.lb | link-format, senml | 402 +-----------------+---------+--------------------+ 404 Table 1: Collection Type Summary 406 The interface description defined in this document describes the 407 methods and functions that may be applied to the collections. 409 4. Interface Descriptions 411 This section defines REST interfaces for Link List, Batch, Sensor, 412 Parameter and Actuator resources. Variants such as Linked Batch or 413 Read-Only Parameter are also presented. Each type is described along 414 with its Interface Description attribute value and valid methods. 415 These are defined for each interface in the table below. These 416 interfaces can support plain text and/or SenML Media types. 418 The if= column defines the Interface Description (if=) attribute 419 value to be used in the CoRE Link Format for a resource conforming to 420 that interface. When this value appears in the if= attribute of a 421 link, the resource MUST support the corresponding REST interface 422 described in this section. The resource MAY support additional 423 functionality, which is out of scope for this document. Although 424 these interface descriptions are intended to be used with the CoRE 425 Link Format, they are applicable for use in any REST interface 426 definition. 428 The Methods column defines the methods supported by that interface, 429 which are described in more detail below. 431 +--------------+---------+-----------------+--------------------+ 432 | Interface | if= | Methods | Content-Formats | 433 +--------------+---------+-----------------+--------------------+ 434 | Link List | core.ll | GET | link-format | 435 | | | | | 436 | Batch | core.b | GET, PUT, POST | link-format, senml | 437 | | | | | 438 | Linked Batch | core.lb | GET, PUT, POST, | link-format, senml | 439 | | | | | 440 | | | DELETE | | 441 | | | | | 442 | Sensor | core.s | GET | link-format, | 443 | | | | | 444 | | | | text/plain | 445 | | | | | 446 | Parameter | core.p | GET, PUT | link-format, | 447 | | | | | 448 | | | | text/plain | 449 | | | | | 450 | Read-only | core.rp | GET | link-format, | 451 | | | | | 452 | Parameter | | | text/plain | 453 | | | | | 454 | Actuator | core.a | GET, PUT, POST | link-format, | 455 | | | | | 456 | | | | text/plain | 457 +--------------+---------+-----------------+--------------------+ 459 Table 2: Interface Description Summary 461 The following is an example of links in the CoRE Link Format using 462 these interface descriptions. The resource hierarchy is based on a 463 simple profile defined in Appendix B. These links are used in the 464 subsequent examples below. 466 Req: GET /.well-known/core 467 Res: 2.05 Content (application/link-format) 468 ;rt="simple.sen";if="core.b", 469 ;rt="simple.sen.lt";if="core.s", 470 ;rt="simple.sen.tmp";if="core.s";obs, 471 ;rt="simple.sen.hum";if="core.s", 472 ;rt="simple.act";if="core.b", 473 ;rt="simple.act.led";if="core.a", 474 ;rt="simple.act.led";if="core.a", 475 ;rt="simple.dev";if="core.ll", 476 ;if="core.lb", 478 Figure 1: Binding Interface Example 480 4.1. Link List 482 The Link List interface is used to retrieve (GET) a list of resources 483 on a web server. The GET request SHOULD contain an Accept option 484 with the application/link-format content format; however if the 485 resource does not support any other form of GET methods the Accept 486 option MAY be elided. The Accept option SHOULD only include the 487 application/link-format content format. 489 _Editor's note: This use of Accept is not very clear, should probably 490 explain this is due to this interface description being extended by 491 Batch and Linked Batch later._ 493 The request returns a list of URI references with absolute paths to 494 the resources as defined in CoRE Link Format. This interface is 495 typically used with a parent resource to enumerate sub-resources but 496 may be used to reference any resource on a web server. 498 Link List is the base interface to provide gradual reveal of 499 resources on a CoRE web server, hence the root resource of a Function 500 Set SHOULD implement this interface or an extension of this 501 interface. 503 The following example interacts with a Link List /d containing 504 Parameter sub-resources /d/name, /d/model. 506 Req: GET /d/ (Accept:application/link-format) 507 Res: 2.05 Content (application/link-format) 508 ;rt="simple.dev.n";if="core.p", 509 ;rt="simple.dev.mdl";if="core.rp" 511 4.2. Batch 513 The Batch interface is used to manipulate a collection of sub- 514 resources at the same time. The Batch interface description supports 515 the same methods as its sub-resources, and can be used to read (GET), 516 update (PUT) or apply (POST) the values of those sub-resource with a 517 single resource representation. The sub-resources of a Batch MAY be 518 heterogeneous, a method used on the Batch only applies to sub- 519 resources that support it. For example Sensor interfaces do not 520 support PUT, and thus a PUT request to a Sensor member of that Batch 521 would be ignored. A batch requires the use of SenML Media types in 522 order to support multiple sub-resources. 524 In addition, The Batch interface is an extension of the Link List 525 interface and in consequence MUST support the same methods. 527 _Editor's note: hould probably explain that this means doing a GET 528 with an Accept:application/link-format will return the sub-resource 529 links_ 531 The following example interacts with a Batch /s/ with Sensor sub- 532 resources /s/light, /s/temp and /s/humidity. 534 Req: GET /s/ 535 Res: 2.05 Content (application/senml+json) 536 {"e":[ 537 { "n": "light", "v": 123, "u": "lx" }, 538 { "n": "temp", "v": 27.2, "u": "degC" }, 539 { "n": "humidity", "v": 80, "u": "%RH" }], 540 } 542 4.3. Linked Batch 544 The Linked Batch interface is an extension of the Batch interface. 545 Contrary to the basic Batch which is a collection statically defined 546 by the web server, a Linked Batch is dynamically controlled by a web 547 client. A Linked Batch resource has no sub-resources. Instead the 548 resources forming the batch are referenced using Web Linking 549 [RFC5988] and the CoRE Link Format [RFC6690]. A request with a POST 550 method and a content format of application/link-format simply appends 551 new resource links to the collection. The links in the payload MUST 552 reference a resource on the web server with an absolute path. A 553 DELETE request removes the entire collection. All other requests 554 available for a basic Batch are still valid for a Linked Batch. 556 The following example interacts with a Linked Batch /l/ and creates a 557 collection containing /s/light, /s/temp and /s/humidity in 2 steps. 559 Req: POST /l/ (Content-Format: application/link-format) 560 , 561 Res: 2.04 Changed 563 Req: GET /l/ 564 Res: 2.05 Content (application/senml+json) 565 {"e":[ 566 { "n": "/s/light", "v": 123, "u": "lx" }, 567 { "n": "/s/temp", "v": 27.2, "u": "degC" }, 568 } 570 Req: POST /l/ (Content-Format: application/link-format) 571 572 Res: 2.04 Changed 574 Req: GET /l/ (Accept: application/link-format) 575 Res: 2.05 Content (application/link-format) 576 ,, 578 Req: GET /l/ 579 Res: 2.05 Content (application/senml+json) 580 {"e":[ 581 { "n": "/s/light", "v": 123, "u": "lx" }, 582 { "n": "/s/temp", "v": 27.2, "u": "degC" }, 583 { "n": "/s/humidity", "v": 80, "u": "%RH" }], 584 } 586 Req: DELETE /l/ 587 Res: 2.02 Deleted 589 4.4. Sensor 591 The Sensor interface allows the value of a sensor resource to be read 592 (GET). The Media type of the resource can be either plain text or 593 SenML. Plain text MAY be used for a single measurement that does not 594 require meta-data. For a measurement with meta-data such as a unit 595 or time stamp, SenML SHOULD be used. A resource with this interface 596 MAY use SenML to return multiple measurements in the same 597 representation, for example a list of recent measurements. 599 The following are examples of Sensor interface requests in both text/ 600 plain and application/senml+json. 602 Req: GET /s/humidity (Accept: text/plain) 603 Res: 2.05 Content (text/plain) 604 80 606 Req: GET /s/humidity (Accept: application/senml+json) 607 Res: 2.05 Content (application/senml+json) 608 {"e":[ 609 { "n": "humidity", "v": 80, "u": "%RH" }], 610 } 612 4.5. Parameter 614 The Parameter interface allows configurable parameters and other 615 information to be modeled as a resource. The value of the parameter 616 can be read (GET) or update (PUT). Plain text or SenML Media types 617 MAY be returned from this type of interface. 619 The following example shows request for reading and updating a 620 parameter. 622 Req: GET /d/name 623 Res: 2.05 Content (text/plain) 624 node5 626 Req: PUT /d/name (text/plain) 627 outdoor 628 Res: 2.04 Changed 630 4.6. Read-only Parameter 632 The Read-only Parameter interface allows configuration parameters to 633 be read (GET) but not updated. Plain text or SenML Media types MAY 634 be returned from this type of interface. 636 The following example shows request for reading such a parameter. 638 Req: GET /d/model 639 Res: 2.05 Content (text/plain) 640 SuperNode200 642 4.7. Actuator 644 The Actuator interface is used by resources that model different 645 kinds of actuators (changing its value has an effect on its 646 environment). Examples of actuators include for example LEDs, 647 relays, motor controllers and light dimmers. The current value of 648 the actuator can be read (GET) or the actuator value can be updated 649 (PUT). In addition, this interface allows the use of POST to change 650 the state of an actuator, for example to toggle between its possible 651 values. Plain text or SenML Media types MAY be returned from this 652 type of interface. A resource with this interface MAY use SenML to 653 include multiple measurements in the same representation, for example 654 a list of recent actuator values or a list of values to updated. 656 The following example shows requests for reading, setting and 657 toggling an actuator (turning on a LED). 659 Req: GET /a/1/led 660 Res: 2.05 Content (text/plain) 661 0 663 Req: PUT /a/1/led (text/plain) 664 1 665 Res: 2.04 Changed 667 Req: POST /a/1/led (text/plain) 668 Res: 2.04 Changed 670 Req: GET /a/1/led 671 Res: 2.05 Content (text/plain) 672 0 674 5. Function Sets and Profiles 676 This section defines how a set of REST resources can be created 677 called a function set. A Function Set is similar to a function block 678 in the sense that it consists of input, output and parameter 679 resources and contains internal logic. A Function Set can have a 680 subset of mandatory inputs, outputs and parameters to provide minimum 681 interoperability. It can also be extended with manufacturer/user- 682 specific resources. A device is composed of one or more Function Set 683 instances. 685 An example of function sets can be found from the CoRE Resource 686 Directory specification that defines REST interfaces for 687 registration, group and lookup [I-D.ietf-core-resource-directory]. 689 The OMA Lightweight M2M standard [OMA-TS-LWM2M] also defines a 690 function set structure called an Objects that use integer path, 691 instance and resource URI segments. OMA Objects can be defined and 692 then registered with an OMA maintained registry [OMA-TS-LWM2M]. This 693 section is simply meant as a guideline for the definition of other 694 such REST interfaces, either custom or part of other specifications. 696 5.1. Defining a Function Set 698 In a Function Set, types of resources are defined. Each type 699 includes a human readable name, a path template, a Resource Type for 700 discovery, the Interface Definition and the data type and allowed 701 values. A Function Set definition may also include a field 702 indicating if a sub-resource is mandatory or optional. 704 5.1.1. Path template 706 A Function Set is a container resource under which its sub-resources 707 are organized. The profile defines the path to each resource of a 708 Function Set in a path template. The template can contain either 709 relative paths or absolute paths depending on the profile needs. An 710 absolute Function Set should be located at its recommended root path 711 on a web server, however it can be located under an alternative path 712 if necessary (for example multi-purpose devices, gateways etc.). A 713 relative Function Set can be instantiated as many times as needed on 714 a web server with an arbitrary root path. However some Function Sets 715 (e.g. device description) only make sense as singletons. 717 The path template includes a possible index {#} parameter, and 718 possible fixed path segments. The index {#} allows for multiple 719 instances of this type of resource, and can be any string. The root 720 path and the indexes are the only variable elements in a path 721 template. All other path segments should be fixed. 723 5.1.2. Resource Type 725 Each root resource of a Function Set is assigned a Resource Type 726 parameter, therefore making it possible to discover it. Each sub- 727 resource of a Function Set is also assigned a Resource Type 728 parameter. This Resource Type is used for resource discovery and is 729 usually necessary to discover optional resources supported on a 730 specific device. The Resource Type of a Function Set may also be 731 used for service discovery and can be exported to DNS-SD [RFC6763] 732 for example. 734 The Resource Type parameter defines the value that should be included 735 in the rt= field of the CoRE Link Format when describing a link to 736 this resource. The value SHOULD be in the form "namespace.type" for 737 root resources and "namespace.type.subtype" for sub-resources. This 738 naming convention facilitates resource type filtering with the 739 /.well-known/core resource. However a profile could allow mixing in 740 foreign namespace references within a Function Set to import external 741 references from other object models (e.g. SenML and UCUM). 743 5.1.3. Interface Description 745 The Interface Description parameter defines the REST interface for 746 that type of resource. Several base interfaces are defined in 747 Section 4 of this document. For a given profile, the Interface 748 Description may be inferred from the Resource Type. In that case the 749 Interface Description MAY be elided from link descriptions of 750 resource types defined in the profile, but should be included for 751 custom extensions to the profile. 753 The root resource of a Function Set should provide a list of links to 754 its sub-resources in order to offer gradual reveal of resources. The 755 CoRE Link List interface defined in Section 7.1 offers this 756 functionality so a root resource should support this interface or a 757 derived interface like CoRE Batch (See Section 7.2). 759 5.1.4. Data type 761 The Data Type field defines the type of value (and possible range) 762 that is returned in response to a GET for that resource or accepted 763 with a PUT. The interfaces defined in Section 4 make use of plain 764 text and SenML Media types for the actual format of this data. A 765 profile may restrict the list of supported content formats for the 766 CoRE interfaces or define new interfaces with new content types. 768 5.2. Discovery 770 A device conforming to a profile SHOULD make its resources 771 discoverable by providing links to the resources on the path /.well- 772 known/core as defined in [RFC6690]. All resources hosted on a device 773 SHOULD be discoverable either with a direct link in /.well-known/core 774 or by following successive links starting from /.well-known/core. 776 The root path of a Function Set instance SHOULD be directly 777 referenced in /.well-known/core in order to offer discovery at the 778 first discovery stage. A device with more than 10 individual 779 resources SHOULD only expose Function Set instances in /.well-known/ 780 core to limit the size of this resource. 782 In addition, a device MAY register its resources to a Resource 783 Directory using the registration interface defined in 784 [I-D.ietf-core-resource-directory] if such a directory is available. 786 5.3. Versioning 788 A profile should track Function Set changes to avoid incompatibility 789 issues. Evolutions in a Function Set SHOULD be backward compatible. 791 6. Security Considerations 793 An implementation of a client needs to be prepared to deal with 794 responses to a request that differ from what is specified in this 795 document. A server implementing what the client thinks is a resource 796 with one of these interface descriptions could return malformed 797 representations and response codes either by accident or maliciously. 798 A server sending maliciously malformed responses could attempt to 799 take advantage of a poorly implemented client for example to crash 800 the node or perform denial of service. 802 7. IANA Considerations 804 This document registers the following CoRE Interface Description 805 (if=) Link Target Attribute Values. 807 7.1. Link List 809 Attribute Value: core.ll 811 Description: The Link List interface is used to retrieve a list of 812 resources on a web server. 814 Reference: This document. Note to RFC Editor - please insert the 815 appropriate RFC reference. 817 Notes: None 819 7.2. Batch 821 Attribute Value: core.b 823 Description: The Batch interface is used to manipulate a collection 824 of sub-resources at the same time. 826 Reference: This document. Note to RFC Editor - please insert the 827 appropriate RFC reference. 829 Notes: None 831 7.3. Linked Batch 833 Attribute Value: core.lb 835 Description: The Linked Batch interface is an extension of the Batch 836 interface. Contrary to the basic Batch which is a collection 837 statically defined by the web server, a Linked Batch is 838 dynamically controlled by a web client. 840 Reference: This document. Note to RFC Editor - please insert the 841 appropriate RFC reference. 843 Notes: None 845 7.4. Sensor 847 Attribute Value: core.s 849 Description: The Sensor interface allows the value of a sensor 850 resource to be read. 852 Reference: This document. Note to RFC Editor - please insert the 853 appropriate RFC reference. 855 Notes: None 857 7.5. Parameter 859 Attribute Value: core.p 861 Description: The Parameter interface allows configurable parameters 862 and other information to be modeled as a resource. The value of 863 the parameter can be read or update. 865 Reference: This document. Note to RFC Editor - please insert the 866 appropriate RFC reference. 868 Notes: None 870 7.6. Read-only parameter 872 Attribute Value: core.rp 874 Description: The Read-only Parameter interface allows configuration 875 parameters to be read but not updated. 877 Reference: This document. Note to RFC Editor - please insert the 878 appropriate RFC reference. 880 Notes: None 882 7.7. Actuator 884 Attribute Value: core.a 886 Description: The Actuator interface is used by resources that model 887 different kinds of actuators (changing its value has an effect on 888 its environment). Examples of actuators include for example LEDs, 889 relays, motor controllers and light dimmers. The current value of 890 the actuator can be read or the actuator value can be updated. In 891 addition, this interface allows the use of POST to change the 892 state of an actuator, for example to toggle between its possible 893 values. 895 Reference: This document. Note to RFC Editor - please insert the 896 appropriate RFC reference. 898 Notes: None 900 8. Acknowledgements 902 Acknowledgement is given to colleagues from the SENSEI project who 903 were critical in the initial development of the well-known REST 904 interface concept, to members of the IPSO Alliance where further 905 requirements for interface descriptions have been discussed, and to 906 Szymon Sasin, Cedric Chauvenet, Daniel Gavelle and Carsten Bormann 907 who have provided useful discussion and input to the concepts in this 908 document. 910 9. Changelog 912 Changes from -05 to -06: 914 o Updated the abstract. 916 o Section 1: Updated introduction. 918 o Section 2: Alphabetised the order 920 o Section 2: Removed the collections definition in favour of the 921 complete definition in the collections section. 923 o Removed section 3 on interfaces in favour of an updated definition 924 in section 1.3. 926 o General: Changed interface type to interface description as that 927 is the term defined in RFC6690. 929 o Removed section on future interfaces. 931 o Section 8: Updated IANA considerations. 933 o Added Appendix A to discuss current state of the art wrt to 934 collections, function sets etc. 936 Changes from -04 to -05: 938 o Removed Link Bindings and Observe attributes. This functionality 939 is now contained in I-D.ietf-core-dynlink. 941 o Hypermedia collections have been removed. This is covered in a 942 new T2TRG draft. 944 o The WADL description has been removed. 946 o Fixed minor typos. 948 o Updated references. 950 Changes from -03 to -04: 952 o Fixed tickets #385 and #386. 954 o Changed abstract and into to better describe content. 956 o Focus on Interface and not function set/profiles in intro. 958 o Changed references from draft-core-observe to RFC7641. 960 o Moved Function sets and Profiles to section after Interfaces. 962 o Moved Observe Attributes to the Link Binding section. 964 o Add a Collection section to describe the collection types. 966 o Add the Hypermedia Collection Interface Description. 968 Changes from -02 to -03: 970 o Added lt and gt to binding format section. 972 o Added pmin and pmax observe parameters to Observation Attributes. 974 o Changed the definition of lt and gt to limit crossing. 976 o Added definitions for getattr and setattr to WADL. 978 o Added getattr and setattr to observable interfaces. 980 o Removed query parameters from Observe definition. 982 o Added observe-cancel definition to WADL and to observable 983 interfaces. 985 Changes from -01 to -02: 987 o Updated the date and version, fixed references. 989 o "Removed pmin and pmax observe parameters "[Ticket #336]"." 991 Changes from -00 to WG Document -01 993 o Improvements to the Function Set section. 995 Changes from -05 to WG Document -00 997 o Updated the date and version. 999 Changes from -04 to -05 1001 o Made the Observation control parameters to be treated as resources 1002 rather than Observe query parameters. Added Less Than and Greater 1003 Than parameters. 1005 Changes from -03 to -04 1007 o Draft refresh 1009 Changes from -02 to -03 1011 o Added Bindings 1013 o Updated all rt= and if= for the new Link Format IANA rules 1015 Changes from -01 to -02 1017 o Defined a Function Set and its guidelines. 1019 o Added the Link List interface. 1021 o Added the Linked Batch interface. 1023 o Improved the WADL interface definition. 1025 o Added a simple profile example. 1027 10. References 1028 10.1. Normative References 1030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1031 Requirement Levels", BCP 14, RFC 2119, 1032 DOI 10.17487/RFC2119, March 1997, 1033 . 1035 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1036 DOI 10.17487/RFC5988, October 2010, 1037 . 1039 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1040 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1041 . 1043 10.2. Informative References 1045 [I-D.ietf-core-dynlink] 1046 Shelby, Z., Vial, M., Koster, M., and C. Groves, "Dynamic 1047 Resource Linking for Constrained RESTful Environments", 1048 draft-ietf-core-dynlink-00 (work in progress), October 1049 2016. 1051 [I-D.ietf-core-resource-directory] 1052 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 1053 Resource Directory", draft-ietf-core-resource-directory-08 1054 (work in progress), July 2016. 1056 [I-D.ietf-core-senml] 1057 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1058 Bormann, "Media Types for Sensor Markup Language (SenML)", 1059 draft-ietf-core-senml-03 (work in progress), October 2016. 1061 [OIC-Core] 1062 "OIC Resource Type Specification v1.1.0", 2016, 1063 . 1065 [OIC-SmartHome] 1066 "OIC Smart Home Device Specification v1.1.0", 2016, 1067 . 1069 [OMA-TS-LWM2M] 1070 "Lightweight Machine to Machine Technical Specification", 1071 2016, . 1075 [oneM2MTS0008] 1076 "TS 0008 v1.3.2 CoAP Protocol Binding", 2016, 1077 . 1079 [oneM2MTS0023] 1080 "TS 0023 v2.0.0 Home Appliances Information Model and 1081 Mapping", 2016, 1082 . 1084 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1085 Resource Identifier (URI): Generic Syntax", STD 66, 1086 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1087 . 1089 [RFC6573] Amundsen, M., "The Item and Collection Link Relations", 1090 RFC 6573, DOI 10.17487/RFC6573, April 2012, 1091 . 1093 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1094 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1095 . 1097 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1098 Protocol (HTTP/1.1): Message Syntax and Routing", 1099 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1100 . 1102 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1103 Application Protocol (CoAP)", RFC 7252, 1104 DOI 10.17487/RFC7252, June 2014, 1105 . 1107 [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, 1108 DOI 10.17487/RFC7396, October 2014, 1109 . 1111 Appendix A. Current Usage of Interfaces and Function Sets 1113 This appendix analyses the current landscape with regards the 1114 definition and use of collections, interfaces and function sets/ 1115 profiles. This should be considered when considering the scope of 1116 this document. 1118 In summary it can be seen that there is a lack of consistancy of the 1119 definition and usage of interface description and function sets. 1121 A.1. Constrained RESTful Environments (CoRE) Link Format (IETF) 1123 [RFC6690] assumes that different deployments or application domains 1124 will define the appropriate REST Interface Descriptions along with 1125 Resource Types to make discovery meaningful. It highlights that 1126 collections are often used for these interfaces. 1128 Whilst 3.2/[RFC6690] defines a new Interface Description 'if' 1129 attribute the procedures around it are about the naming of the 1130 interface not what information should be included in the 1131 documentation about the interface. 1133 Function sets are not discussed. 1135 A.2. CoRE Resource Directory (IETF) 1137 [I-D.ietf-core-resource-directory] uses the concepts of collections, 1138 interfaces and function sets. 1140 If defines a number of interfaces: discovery, registration, 1141 registration update, registration removal, read endpoint links, 1142 update endpoint links, registration request interface, removal 1143 request interface and lookup interface. However it does not assign 1144 an inteface description identifier (if=) to these interfaces. 1146 It does define a resource directory function set which specifies 1147 relevant content formats and interfaces to be used between a resource 1148 directory and endpoints. However it does not follow the format 1149 proposed by this document. 1151 A.3. Open Connectivity Foundation (OCF) 1153 The OIC Core Specification [OIC-Core] most closely aligns with the 1154 work in this specification. It makes use of interface descriptions 1155 as per [RFC6690] and has registered several interface identifiers 1156 (https://www.iana.org/assignments/core-parameters/core- 1157 parameters.xhtml#if-link-target-att-value). These interface 1158 descriptors are similar to those defined in this specification. From 1159 a high level perspective: 1161 links list: OCF (oic.if.ll) -> IETF (core.ll) 1162 Note: it's called "link list" in the IETF. 1163 linked batch: OCF (oic.if.b) -> IETF (core.lb) 1164 read-only: OCF (oic.if.r) -> IETF (core.rp) 1165 read-write: OCF (oic.if.rw) -> IETF (core.p) 1166 actuator: OCF (oic.if.a) -> IETF (core.a) 1167 sensor: OCF (oic.if.s) -> IETF (core.s) 1168 batch: No OCF equivalent -> IETF (core.b) 1169 Some of the OCF interfaces make use of collections. 1171 The OIC Core specification does not use the concept of function sets. 1172 It does however discuss the concept of profiles. The OCF defines two 1173 sets of documents. The core specification documents such as 1174 [OIC-Core] and vertical profile specification documents which provide 1175 specific information for specific applications. The OIC Smart Home 1176 Device Specification [OIC-SmartHome] is one such specification. It 1177 provides information on the resource model, discovery and data types. 1179 A.4. oneM2M 1181 OneM2M describes a technology independent functional architecture 1182 [oneM2MTS0023]. In this archictecture the reference points between 1183 functional entities are called "interfaces". This usage does not 1184 match the [RFC6690] concept of interfaces. A more direct comparison 1185 is that of 10.2/[oneM2MTS0023] that defines basic procedures and 1186 resource type-specific procedures utilising REST type create, 1187 retrieve, update, delete, notify actions. 1189 [oneM2MTS0023] does not refer to resource collections however does 1190 define "Group Management Procedures" in 10.2.7/[oneM2MTS0023]. It 1191 does allow bulk management of member resources. 1193 [oneM2MTS0023] does not use the term "function set". [oneM2MTS0008] 1194 describes the binding with the CoAP protocol. In some respects this 1195 document provides a profile of the CoAP protocol in terms of the 1196 protocol elements that need to be supported. However it does not 1197 define any interface descriptions nor collections. 1199 A.5. OMA LWM2M 1201 [OMA-TS-LWM2M] utilises the concept of interfaces. It defines the 1202 following interfaces: Bootstrap, Client Registration, Device 1203 Management and Service Enablement and Information Reporting. It 1204 defines that these have a particular direction (Uplink/Downlink) and 1205 indicates the operations that may be applied to the interface (i.e. 1206 Request Bootstrap, Write, Delete, Register, Update, De-Register, 1207 Create, Read, Write, Delete, Execute, Write Attributes, Discover, 1208 Observe, Cancel Observation, Notify). It then further defines which 1209 objects may occur over the interface. In 6/[OMA-TS-LWM2M] resource 1210 model, identifier and data formats are described. 1212 Whilst it does not formally describe the use of "collections" the use 1213 of a multiple resource TLV allows a hierarchy of resource/sub- 1214 resource. 1216 It does not identify the interfaces through an Interface Description 1217 (if=) attribute. 1219 It does not use the term function set. Informally the specification 1220 could be considered as a function set. 1222 Note: It refers to draft-ietf-core-interfaces-00. It also makes use 1223 of the binding/observation attributes from draft-ietf-dynlink-00 but 1224 does not refer to that document. 1226 Appendix B. Profile example 1228 The following is a short definition of simple profile. This 1229 simplistic profile is for use in the examples of this document. 1231 +--------------------+-----------+------------+---------+ 1232 | Function Set | Root Path | RT | IF | 1233 +--------------------+-----------+------------+---------+ 1234 | Device Description | /d | simple.dev | core.ll | 1235 | | | | | 1236 | Sensors | /s | simple.sen | core.b | 1237 | | | | | 1238 | Actuators | /a | simple.act | core.b | 1239 +--------------------+-----------+------------+---------+ 1241 Table 3: List of Function Sets 1243 +-------+----------+----------------+---------+------------+ 1244 | Type | Path | RT | IF | Data Type | 1245 +-------+----------+----------------+---------+------------+ 1246 | Name | /d/name | simple.dev.n | core.p | xsd:string | 1247 | | | | | | 1248 | Model | /d/model | simple.dev.mdl | core.rp | xsd:string | 1249 +-------+----------+----------------+---------+------------+ 1251 Table 4: Device Description Function Set 1253 +-------------+-------------+----------------+--------+-------------+ 1254 | Type | Path | RT | IF | Data Type | 1255 +-------------+-------------+----------------+--------+-------------+ 1256 | Light | /s/light | simple.sen.lt | core.s | xsd:decimal | 1257 | | | | | | 1258 | | | | | (lux) | 1259 | | | | | | 1260 | Humidity | /s/humidity | simple.sen.hum | core.s | xsd:decimal | 1261 | | | | | | 1262 | | | | | (%RH) | 1263 | | | | | | 1264 | Temperature | /s/temp | simple.sen.tmp | core.s | xsd:decimal | 1265 | | | | | | 1266 | | | | | (degC) | 1267 +-------------+-------------+----------------+--------+-------------+ 1269 Table 5: Sensors Function Set 1271 +------+------------+----------------+--------+-------------+ 1272 | Type | Path | RT | IF | Data Type | 1273 +------+------------+----------------+--------+-------------+ 1274 | LED | /a/{#}/led | simple.act.led | core.a | xsd:boolean | 1275 +------+------------+----------------+--------+-------------+ 1277 Table 6: Actuators Function Set 1279 Authors' Addresses 1281 Zach Shelby 1282 ARM 1283 150 Rose Orchard 1284 San Jose 95134 1285 FINLAND 1287 Phone: +1-408-203-9434 1288 Email: zach.shelby@arm.com 1290 Matthieu Vial 1291 Schneider-Electric 1292 Grenoble 1293 FRANCE 1295 Phone: +33 (0)47657 6522 1296 Email: matthieu.vial@schneider-electric.com 1297 Michael Koster 1298 SmartThings 1299 665 Clyde Avenue 1300 Mountain View 94043 1301 USA 1303 Email: michael.koster@smartthings.com 1305 Christian Groves 1306 Huawei 1307 Australia 1309 Email: Christian.Groves@nteczone.com