idnits 2.17.00 (12 Aug 2021) /tmp/idnits41398/draft-bormann-t2trg-ble-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2016) is 2136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational A. Keranen 5 Expires: January 9, 2017 Ericsson 6 July 08, 2016 8 The BLE (Bluetooth Low Energy) URI Scheme and Media Types 9 draft-bormann-t2trg-ble-uri-00 11 Abstract 13 In addition to its use as a subnetwork layer for IP (e.g., via 14 RFC 7668), in various IoT web applications Bluetooth Low Energy (BLE) 15 can serve as a "local interconnect", connecting devices locally 16 (i.e., not over IP) for use as a source of information and a target 17 for actuation. In order to fully use these capabilities in 18 applications using web technologies, there is a need for a method for 19 addressing the resources, i.e., a URI scheme, and definition of the 20 representation of the data exchanged between the application and 21 devices, i.e., media types. This document is a straw man proposal 22 for such a URI scheme and media types for interacting with the 23 Bluetooth GAP and GATT protocols. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 9, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Access to local resources via Bluetooth Low Energy . . . . . 3 62 3. Media types . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. application/ble-nodelist . . . . . . . . . . . . . . . . 5 64 3.2. application/ble-gap-enablement . . . . . . . . . . . . . 6 65 3.3. application/ble-gap-nameinfo . . . . . . . . . . . . . . 6 66 3.4. application/ble-gatt-servicelist . . . . . . . . . . . . 6 67 3.5. application/ble-gatt-characteristics . . . . . . . . . . 6 68 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 4.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 In the context of the W3C Web of Things (WoT) Interest Group work, 76 the need to address both resources connected over the Internet of 77 Things and those connected over a "local interconnect" has been 78 raised. The present document is a straw man proposal for a URI 79 format addressing the latter kind, using the example of the Bluetooth 80 GAP and GATT protocols. 82 The Bluetooth GAP and GATT REST API white papers [BT-GAP-REST] 83 [BT-GATT-REST] describe how an HTTP gateway can be used for 84 interacting with Bluetooth devices and their resources over the 85 Internet, using HTTP. If a Bluetooth device is IP-enabled (e.g., 86 [RFC7668]), also regular IP protocols (e.g., CoAP) and URI schemes 87 can be used for end-to-end communication. When a web application is 88 running on a Bluetooth device, or the Bluetooth device is directly 89 connected to the same device where the web application is running, IP 90 communication is not always necessary but a mechanism for addressing 91 the resources is still needed. This document specifies a URI scheme 92 for addressing such locally connected Bluetooth resources and 93 functionality. 95 In addition to locally connected resources, a BLE URI scheme can be 96 used to address resources on a remote host that implements a proxy 97 supporting both the BLE scheme and another scheme that is possible to 98 use over a network (e.g., HTTP or CoAP). 100 The focus of this document is on interaction with the attributes and 101 characteristics that would be exposed as resources for an IoT web 102 application. That is, functionality such as being able to create 103 synchronous audio connection with a Bluetooth headset is out of 104 scope. 106 (Note that the version you are looking at is less than half-way 107 complete. We plan to fill in the rest of the proposal after 108 receiving some initial feedback about the general approach.) 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in RFC 115 2119 [RFC2119]. 117 GAP and GATT are protocols defined in [BTCorev4.2]. 119 Terminology for constrained nodes and constrained node networks can 120 be found in [RFC7228]. 122 In this specification, the term "byte" is used in its now customary 123 sense as a synonym for "octet". 125 All multi-byte integers in this specification are interpreted in 126 network byte order. 128 Enabled nodes: Nodes that have been configures for automatic 129 connection (and reconnection each time a connection is lost). 131 2. Access to local resources via Bluetooth Low Energy 133 For GAP, clients operating in the GAP Central and Observer roles 134 [BTCorev4.2] are supported. Security setup ("pairing") and the 135 specifics of link encryption are out of scope for this version of the 136 present document. Specifically, there is an assumption that any 137 necessary access control to nodes and resources on these nodes is 138 performed when the URIs defined in this document are operated. 140 The following URIs are predefined: 142 +------------------------+-------------------------+-----+--------+ 143 | URI | Semantics | Op. | Result | 144 +------------------------+-------------------------+-----+--------+ 145 | ble:/gap/nodes/passive | passive scan for nodes | GET | (1) | 146 | | | | | 147 | ble:/gap/nodes/active | active scan for nodes | GET | (1) | 148 | | | | | 149 | ble:/gap/nodes/enabled | scan for enabled nodes | GET | (1) | 150 | | | | | 151 | ble:/gatt/nodes | list of available nodes | GET | (2) | 152 +------------------------+-------------------------+-----+--------+ 154 The GAP operations return gap node links, operations on which are 155 detailed below. The implementation is free to choose the form of 156 these node links, e.g. from the template "ble:/gap/node/{handle}". 158 +---------------+-------------------------------+-----+--------+ 159 | URI | Semantics | Op. | Result | 160 +---------------+-------------------------------+-----+--------+ 161 | {node} | Information about node {node} | GET | (1) | 162 | | | | | 163 | {node}/enable | Enablement of {node} | PUT | (3) | 164 | | | | | 165 | {node}/name | Name of {node} | GET | (4) | 166 +---------------+-------------------------------+-----+--------+ 168 The above GATT operations return gatt node links, operations on which 169 are detailed below. Again, the implementation is free to choose the 170 form of these node links, e.g. from the template "ble:/gatt/ 171 node/{handle}". [[twotypes: Do we really need two types of node 172 links or are the GAP and GATT ones possibly interchangeable?]] 174 +-----------------+----------------------------+-----+--------+ 175 | URI | Semantics | Op. | Result | 176 +-----------------+----------------------------+-----+--------+ 177 | {node}/services | Services offered by {node} | GET | (5) | 178 +-----------------+----------------------------+-----+--------+ 180 The above GATT operations return gatt service links, operations on 181 which are detailed below. Again, the implementation is free to 182 choose the form of these node links, e.g. from the template 183 "ble:/gatt/service/{nodehandle}/{servicehandle}". [[nodesvsservices: 184 In the current draft, it is not always clear whether a node leads to 185 some resource or the client needs to go through a service to get 186 there. This needs to be clarified (or possibly unified).]] 187 +-------------------------------+--------------------+-----+--------+ 188 | URI | Semantics | Op. | Result | 189 +-------------------------------+--------------------+-----+--------+ 190 | {service}/secondaryservices | Secondary services | GET | (5) | 191 | | for {service} | | | 192 | | | | | 193 | {service}/characteristics | Characteristics of | GET | (6) | 194 | | {service} | | | 195 | | | | | 196 | {node}/{uuid}/characteristics | {uuid} | GET | (6) | 197 | | Characteristics of | | | 198 | | {node} | | | 199 +-------------------------------+--------------------+-----+--------+ 201 +-----+-------------------------------------------------------+ 202 | | media type | 203 +-----+-------------------------------------------------------+ 204 | (1) | application/ble-nodelist+json or +cbor | 205 | | | 206 | (2) | application/ble-nodelist+json or +cbor, no attributes | 207 | | | 208 | (3) | application/ble-gap-enablement+json or +cbor | 209 | | | 210 | (4) | application/ble-gap-nameinfo+json or +cbor | 211 | | | 212 | (5) | application/ble-gatt-servicelist+json or +cbor | 213 | | | 214 | (5) | application/ble-gatt-characteristics+json or +cbor | 215 +-----+-------------------------------------------------------+ 217 3. Media types 219 The media types below are tentatively defined in CDDL, for both JSON 220 (add +json) and CBOR (add +cbor) use. Where the type "bytes" is used 221 with JSON, the representation is a base64url [RFC4648] string. 222 [[separatemediatypes: In the next version, we might possibly move to 223 a single media type that has a choice between all these formats.]] 225 3.1. application/ble-nodelist 226 nodelist = [* node] 227 node = { 228 href: text, ; link to that specific node 229 bdaddr: bdaddr, 230 ? ad: attributelist, ; only for GAP use 231 } 233 bdaddr = bytes .size 6 235 attributelist = [* attribute] ; could this be a map? 236 attribute = [attributename, bytes] 237 attributename = text 239 3.2. application/ble-gap-enablement 241 enablement = { 242 enabled: bool, 243 ? interval: uint, ; define what unit 244 ? latency: uint, ; define what unit 245 } 247 3.3. application/ble-gap-nameinfo 249 node = { 250 href: text, ; link to that specific node 251 name: text, 252 } 254 3.4. application/ble-gatt-servicelist 256 servicelist = [* service] 257 service = { 258 href: text, 259 uuid: uuid, 260 } 262 uuid = bytes .size 16 264 3.5. application/ble-gatt-characteristics 265 characteristics = [* characteristic] 266 characteristic = { 267 href: text, ; link for this characteristic 268 properties: properties, 269 } 271 properties = bytes .bits property 272 property = &( 273 Broadcast: 0 274 Readable: 1 275 Writable-with-no-response: 2 276 Writable: 3 277 Notify: 4 278 Indicate: 5 279 Authenticated-signed-write: 6 280 Extended-property-available: 7 281 ) 283 4. References 285 4.1. Normative References 287 [BT-GAP-REST] 288 Bluetooth Special Interest Group, Internet Working Group, 289 "GAP REST API White Paper", April 2014, 290 . 293 [BT-GATT-REST] 294 Bluetooth Special Interest Group, Internet Working Group, 295 "GATT REST API White Paper", April 2014, 296 . 299 [BTCorev4.2] 300 Bluetooth Special Interest Group, "Bluetooth Core 301 Specification Version 4.2", December 2014, 302 . 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 307 RFC2119, March 1997, 308 . 310 4.2. Informative References 312 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 313 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 314 . 316 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 317 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 318 RFC7228, May 2014, 319 . 321 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 322 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 323 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 324 . 326 Authors' Addresses 328 Carsten Bormann 329 Universitaet Bremen TZI 330 Postfach 330440 331 Bremen D-28359 332 Germany 334 Phone: +49-421-218-63921 335 Email: cabo@tzi.org 337 Ari Keranen 338 Ericsson 339 Jorvas 02420 340 Finland 342 Email: ari.keranen@ericsson.com