| Network Working Group | L. Sunde |
| Internet-Draft | Uppsala University |
| Intended status: Standards Track | July 03, 2013 |
| Expires: January 04, 2014 |
The NetInf Bluetooth Convergence Layer
draft-sunde-netinf-protocol-bluetooth-00
This document defines a Network of Information (NetInf) convergence layer intended to be used over some Bluetooth protocol providing reliable transmission. A convergence layer handles the transport of NetInf requests and responses. In this convergence layer the common NetInf messages are defined using JavaScript Object Notation (JSON) and Named Data Object (NDO) octet parts, both using length prefixes. While the convergence layer is intended to be used over Bluetooth, any underlying protocol providing reliable transmission could potentially be used.
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 04, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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 RFC 2119 [RFC2119].
This section specifies a NetInf Convergence Layer [I-D.kutscher-icnrg-netinf-proto] intended to be used over Bluetooth. The protocol does not provide reliable transmission. This is assumed to be provided by the underlying Bluetooth protocol, e.g. radio frequency communication (RFCOMM). The Bluetooth convergence layer (BCL) could potentially also be used on top of non-Bluetooth protocols providing the required features (e.g. TCP).
The BCL does not provide any means of discovering or selecting which devices to route to. This problem must be handled by the implementation. A Bluetooth connection needs to be established between the sender and the receiver. This connection MAY use RFCOMM [RFCOMM]. It MAY be established using the service discovery protocol [SDAP] with the Universally Unique IDentifier [RFC4122] 111a8500-6ae2-11e2-bcfd-0800200c9a66.
The response to a request SHOULD be sent back using the same connection (if two-way communication is supported) but an implementation MUST NOT assume that this always is the case.
The protocol is built around sending UTF-8 [RFC3629] encoded JSON and NDO octets through a stream providing reliable transmission. All JSON and octet parts MUST be prefixed with their length in bytes. The length prefix MUST be a 32-bit signed integer encoded in two's complement using big endian network byte order.
The ni URI scheme [RFC6920] MUST be supported. Other URI schemes MAY be supported.
The following names are defined for JSON name/value pairs:
------------------------------------------------------------------
Name | Value | Comments
------------------------------------------------------------------
type | string | Message type. MUST be "publish",
| | "publish-response", "get", "get-response",
| | "search" or "search-response".
------------------------------------------------------------------
msgid | string | Message identifier.
------------------------------------------------------------------
uri | string | NDO URI.
------------------------------------------------------------------
hoplimit | number | Number of times to forward this message.
| | Assumed to be 0 if not present.
------------------------------------------------------------------
locators | [string] | Locators to the NDO.
------------------------------------------------------------------
ext | object | Metadata and future extensions. Metadata
| | MUST be an object under the "meta" key if
| | present. E.g. "ext":{"meta":{...}}
------------------------------------------------------------------
octets | true/false | Flag indicating if this JSON is directly
| | followed by the NDO octets (including the
| | length prefix). Assumed to be false if
| | not present.
------------------------------------------------------------------
status | number | Code indicating the status of a response.
------------------------------------------------------------------
tokens | [string] | Tokens used in a SEARCH. MUST contain at
| | least one token.
------------------------------------------------------------------
results | [object] | The results of a search. See Section 2.6.
------------------------------------------------------------------
Figure 1: Bluetooth CL JSON
A PUBLISH MUST start with a JSON part (including the associated length prefix). The JSON part MUST include the following name/value pairs:
Where "type" MUST be "publish" and "uri" MUST be the URI of the NDO being published.
The JSON part MAY also include:
If "octets" is present and true, the JSON part MUST be followed by the octets of the NDO (including the associated length prefix). If "octets" is not present or false, the JSON part MUST NOT be followed by the octets.
A PUBLISH-RESP MUST consist of a single JSON part. The JSON part MUST include the following name/value pairs:
Where "type" MUST be "publish-response".
A GET MUST consist of a single JSON part. The JSON part MUST include the following name/value pairs:
Where "type" MUST be "get".
The JSON part MAY also include:
A GET-RESP MUST start with a JSON part. The JSON part MUST include the following name/value pairs:
Where "type" MUST be "get-response" and "uri" MUST be the URI requested NDO.
The JSON part MAY also include:
If "octets" is present and true, the JSON part MUST be followed by the octets of the requested NDO. If "octets" is not present or false, the JSON part MUST NOT be followed by the octets.
A SEARCH MUST consist of a single JSON part. The JSON part MUST include the following name/value pairs:
Where "type" MUST be "search".
The JSON part MAY also include:
A SEARCH-RESP MUST consist of a single JSON part. The JSON part MUST include the following name/value pairs:
Where "type" MUST be "search-response".
------------------------------------------------------------------
Name | Value | Comments
------------------------------------------------------------------
ni | string | The ni URI of the matching NDO.
| | MUST be included.
------------------------------------------------------------------
metadata | object | Metadata belonging to the matching NDO.
| | MAY be included.
------------------------------------------------------------------
Figure 2: Search result JSON
Each object in the "results" array represents an NDO considered to match the tokens included in the corresponding SEARCH. If no matching NDOs were found "results" might be empty. The following name/value pairs are defined for the search result objects:
As mentioned in [I-D.kutscher-icnrg-netinf-proto] requesters SHOULD attempt to limit the amount of personally identifying information for privacy reasons. Care should be taken when generating SEARCH tokens and when responding to a SEARCH.
Validation of name-data integrity is important. Consider a scenario where the connected Bluetooth devices are a number of smart phones that happen to be in close proximity. The other devices can not be trusted to send the correct data and might even try to send malicious data.
In the smart phone case battery life is also something to take into consideration. By requesting data over and over again a requester could intentionally drain the battery of the responder.
This document has no actions for IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3629] | Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. |
| [I-D.kutscher-icnrg-netinf-proto] | Kutscher, D., Farrell, S. and E. Davies, "The NetInf Protocol", Internet-Draft draft-kutscher-icnrg-netinf-proto-01, February 2013. |
| [RFC6920] | Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A. and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013. |
| [RFCOMM] | Bluetooth Special Interest Group , "RFCOMM with TS 07.10 Serial Port Emulation", November 2012. |
| [SDAP] | Bluetooth Special Interest Group , "Service Discovery Application Profile", February 2001. |
| [RFC4122] | Leach, P., Mealling, M. and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. |