]> Uppsala University

Uppsala Sweden Linus.Sunde.9273@student.uu.se

IETF Network Working Group Network of Information Information centric networking NetInf Bluetooth 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.

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 .

This section specifies a NetInf Convergence Layer 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 . It MAY be established using the service discovery protocol with the Universally Unique IDentifier 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 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 MUST be supported. Other URI schemes MAY be supported. The following names are defined for JSON name/value pairs:

A PUBLISH MUST start with a JSON part (including the associated length prefix). The JSON part MUST include the following name/value pairs: type msgid uri Where "type" MUST be "publish" and "uri" MUST be the URI of the NDO being published. The JSON part MAY also include: hoplimit locators ext octets 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: type status msgid 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: type msgid uri Where "type" MUST be "get". The JSON part MAY also include: hoplimit

A GET-RESP MUST start with a JSON part. The JSON part MUST include the following name/value pairs: type status msgid uri Where "type" MUST be "get-response" and "uri" MUST be the URI requested NDO. The JSON part MAY also include: locators octets 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: type msgid tokens Where "type" MUST be "search". The JSON part MAY also include: hoplimit

A SEARCH-RESP MUST consist of a single JSON part. The JSON part MUST include the following name/value pairs: type status msgid results Where "type" MUST be "search-response". 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 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; ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. This document defines a conceptual protocol and corresponding node requirements for NetInf nodes in a NetInf network. A NetInf network offers an information-centric paradigm that supports the creation, location, exchange and storage of Named Data Objects (NDOs). NetInf nodes can provide different services to other NetInf nodes, e.g., forwarding requests for information objects, delivering corresponding response messages, name resolution services etc. This (abstract) protocol is intended to be run over some "convergence layer" that handles transport issues. Two "wire" formats are defined, one that uses HTTP for message transfer and one layered on UDP. This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. Bluetooth Special Interest Group This document specifies the RFCOMM protocol by specifying a subset of the ETSI TS 07.10 standard, along with some Bluetooth-specific adaptations. Bluetooth Special Interest Group This document defines the features and procedures for an application in a Bluetooth device to discover services registered in other Bluetooth devices and retrieve any desired available information pertinent to these services. Microsoft

1 Microsoft Way Redmond WA 98052 US +1 425-882-8080 paulle@microsoft.com

Refactored Networks, LLC

1635 Old Hwy 41 Suite 112, Box 138 Kennesaw GA 30152 US +1-678-581-9656 michael@refactored-networks.com http://www.refactored-networks.com

DataPower Technology, Inc.

1 Alewife Center Cambridge MA 02142 US +1 617-864-0455 rsalz@datapower.com http://www.datapower.com

URN, UUID This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document.