CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational A. Keranen
Expires: January 9, 2017 Ericsson
July 08, 2016
The BLE (Bluetooth Low Energy) URI Scheme and Media Types
draft-bormann-t2trg-ble-uri-00
Abstract
In addition to its use as a subnetwork layer for IP (e.g., via
RFC 7668), in various IoT web applications Bluetooth Low Energy (BLE)
can serve as a "local interconnect", connecting devices locally
(i.e., not over IP) for use as a source of information and a target
for actuation. In order to fully use these capabilities in
applications using web technologies, there is a need for a method for
addressing the resources, i.e., a URI scheme, and definition of the
representation of the data exchanged between the application and
devices, i.e., media types. This document is a straw man proposal
for such a URI scheme and media types for interacting with the
Bluetooth GAP and GATT protocols.
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 9, 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
Bormann & Keranen Expires January 9, 2017 [Page 1]
Internet-Draft concert July 2016
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Access to local resources via Bluetooth Low Energy . . . . . 3
3. Media types . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. application/ble-nodelist . . . . . . . . . . . . . . . . 5
3.2. application/ble-gap-enablement . . . . . . . . . . . . . 6
3.3. application/ble-gap-nameinfo . . . . . . . . . . . . . . 6
3.4. application/ble-gatt-servicelist . . . . . . . . . . . . 6
3.5. application/ble-gatt-characteristics . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . 7
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In the context of the W3C Web of Things (WoT) Interest Group work,
the need to address both resources connected over the Internet of
Things and those connected over a "local interconnect" has been
raised. The present document is a straw man proposal for a URI
format addressing the latter kind, using the example of the Bluetooth
GAP and GATT protocols.
The Bluetooth GAP and GATT REST API white papers [BT-GAP-REST]
[BT-GATT-REST] describe how an HTTP gateway can be used for
interacting with Bluetooth devices and their resources over the
Internet, using HTTP. If a Bluetooth device is IP-enabled (e.g.,
[RFC7668]), also regular IP protocols (e.g., CoAP) and URI schemes
can be used for end-to-end communication. When a web application is
running on a Bluetooth device, or the Bluetooth device is directly
connected to the same device where the web application is running, IP
communication is not always necessary but a mechanism for addressing
the resources is still needed. This document specifies a URI scheme
for addressing such locally connected Bluetooth resources and
functionality.
In addition to locally connected resources, a BLE URI scheme can be
used to address resources on a remote host that implements a proxy
Bormann & Keranen Expires January 9, 2017 [Page 2]
Internet-Draft concert July 2016
supporting both the BLE scheme and another scheme that is possible to
use over a network (e.g., HTTP or CoAP).
The focus of this document is on interaction with the attributes and
characteristics that would be exposed as resources for an IoT web
application. That is, functionality such as being able to create
synchronous audio connection with a Bluetooth headset is out of
scope.
(Note that the version you are looking at is less than half-way
complete. We plan to fill in the rest of the proposal after
receiving some initial feedback about the general approach.)
1.1. Terminology
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 RFC
2119 [RFC2119].
GAP and GATT are protocols defined in [BTCorev4.2].
Terminology for constrained nodes and constrained node networks can
be found in [RFC7228].
In this specification, the term "byte" is used in its now customary
sense as a synonym for "octet".
All multi-byte integers in this specification are interpreted in
network byte order.
Enabled nodes: Nodes that have been configures for automatic
connection (and reconnection each time a connection is lost).
2. Access to local resources via Bluetooth Low Energy
For GAP, clients operating in the GAP Central and Observer roles
[BTCorev4.2] are supported. Security setup ("pairing") and the
specifics of link encryption are out of scope for this version of the
present document. Specifically, there is an assumption that any
necessary access control to nodes and resources on these nodes is
performed when the URIs defined in this document are operated.
The following URIs are predefined:
Bormann & Keranen Expires January 9, 2017 [Page 3]
Internet-Draft concert July 2016
+------------------------+-------------------------+-----+--------+
| URI | Semantics | Op. | Result |
+------------------------+-------------------------+-----+--------+
| ble:/gap/nodes/passive | passive scan for nodes | GET | (1) |
| | | | |
| ble:/gap/nodes/active | active scan for nodes | GET | (1) |
| | | | |
| ble:/gap/nodes/enabled | scan for enabled nodes | GET | (1) |
| | | | |
| ble:/gatt/nodes | list of available nodes | GET | (2) |
+------------------------+-------------------------+-----+--------+
The GAP operations return gap node links, operations on which are
detailed below. The implementation is free to choose the form of
these node links, e.g. from the template "ble:/gap/node/{handle}".
+---------------+-------------------------------+-----+--------+
| URI | Semantics | Op. | Result |
+---------------+-------------------------------+-----+--------+
| {node} | Information about node {node} | GET | (1) |
| | | | |
| {node}/enable | Enablement of {node} | PUT | (3) |
| | | | |
| {node}/name | Name of {node} | GET | (4) |
+---------------+-------------------------------+-----+--------+
The above GATT operations return gatt node links, operations on which
are detailed below. Again, the implementation is free to choose the
form of these node links, e.g. from the template "ble:/gatt/
node/{handle}". [[twotypes: Do we really need two types of node
links or are the GAP and GATT ones possibly interchangeable?]]
+-----------------+----------------------------+-----+--------+
| URI | Semantics | Op. | Result |
+-----------------+----------------------------+-----+--------+
| {node}/services | Services offered by {node} | GET | (5) |
+-----------------+----------------------------+-----+--------+
The above GATT operations return gatt service links, operations on
which are detailed below. Again, the implementation is free to
choose the form of these node links, e.g. from the template
"ble:/gatt/service/{nodehandle}/{servicehandle}". [[nodesvsservices:
In the current draft, it is not always clear whether a node leads to
some resource or the client needs to go through a service to get
there. This needs to be clarified (or possibly unified).]]
Bormann & Keranen Expires January 9, 2017 [Page 4]
Internet-Draft concert July 2016
+-------------------------------+--------------------+-----+--------+
| URI | Semantics | Op. | Result |
+-------------------------------+--------------------+-----+--------+
| {service}/secondaryservices | Secondary services | GET | (5) |
| | for {service} | | |
| | | | |
| {service}/characteristics | Characteristics of | GET | (6) |
| | {service} | | |
| | | | |
| {node}/{uuid}/characteristics | {uuid} | GET | (6) |
| | Characteristics of | | |
| | {node} | | |
+-------------------------------+--------------------+-----+--------+
+-----+-------------------------------------------------------+
| | media type |
+-----+-------------------------------------------------------+
| (1) | application/ble-nodelist+json or +cbor |
| | |
| (2) | application/ble-nodelist+json or +cbor, no attributes |
| | |
| (3) | application/ble-gap-enablement+json or +cbor |
| | |
| (4) | application/ble-gap-nameinfo+json or +cbor |
| | |
| (5) | application/ble-gatt-servicelist+json or +cbor |
| | |
| (5) | application/ble-gatt-characteristics+json or +cbor |
+-----+-------------------------------------------------------+
3. Media types
The media types below are tentatively defined in CDDL, for both JSON
(add +json) and CBOR (add +cbor) use. Where the type "bytes" is used
with JSON, the representation is a base64url [RFC4648] string.
[[separatemediatypes: In the next version, we might possibly move to
a single media type that has a choice between all these formats.]]
3.1. application/ble-nodelist
Bormann & Keranen Expires January 9, 2017 [Page 5]
Internet-Draft concert July 2016
nodelist = [* node]
node = {
href: text, ; link to that specific node
bdaddr: bdaddr,
? ad: attributelist, ; only for GAP use
}
bdaddr = bytes .size 6
attributelist = [* attribute] ; could this be a map?
attribute = [attributename, bytes]
attributename = text
3.2. application/ble-gap-enablement
enablement = {
enabled: bool,
? interval: uint, ; define what unit
? latency: uint, ; define what unit
}
3.3. application/ble-gap-nameinfo
node = {
href: text, ; link to that specific node
name: text,
}
3.4. application/ble-gatt-servicelist
servicelist = [* service]
service = {
href: text,
uuid: uuid,
}
uuid = bytes .size 16
3.5. application/ble-gatt-characteristics
Bormann & Keranen Expires January 9, 2017 [Page 6]
Internet-Draft concert July 2016
characteristics = [* characteristic]
characteristic = {
href: text, ; link for this characteristic
properties: properties,
}
properties = bytes .bits property
property = &(
Broadcast: 0
Readable: 1
Writable-with-no-response: 2
Writable: 3
Notify: 4
Indicate: 5
Authenticated-signed-write: 6
Extended-property-available: 7
)
4. References
4.1. Normative References
[BT-GAP-REST]
Bluetooth Special Interest Group, Internet Working Group,
"GAP REST API White Paper", April 2014,
<https://www.bluetooth.com/develop-with-bluetooth/white-
papers>.
[BT-GATT-REST]
Bluetooth Special Interest Group, Internet Working Group,
"GATT REST API White Paper", April 2014,
<https://www.bluetooth.com/develop-with-bluetooth/white-
papers>.
[BTCorev4.2]
Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.2", December 2014,
<https://www.bluetooth.org/en-us/specification/adopted-
specifications>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Bormann & Keranen Expires January 9, 2017 [Page 7]
Internet-Draft concert July 2016
4.2. Informative References
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/
RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
Authors' Addresses
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Ari Keranen
Ericsson
Jorvas 02420
Finland
Email: ari.keranen@ericsson.com
Bormann & Keranen Expires January 9, 2017 [Page 8]