idnits 2.17.1 draft-sunde-netinf-protocol-bluetooth-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2013) is 3948 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Sunde 3 Internet-Draft Uppsala University 4 Intended status: Standards Track July 03, 2013 5 Expires: January 04, 2014 7 The NetInf Bluetooth Convergence Layer 8 draft-sunde-netinf-protocol-bluetooth-00 10 Abstract 12 This document defines a Network of Information (NetInf) convergence 13 layer intended to be used over some Bluetooth protocol providing 14 reliable transmission. A convergence layer handles the transport of 15 NetInf requests and responses. In this convergence layer the common 16 NetInf messages are defined using JavaScript Object Notation (JSON) 17 and Named Data Object (NDO) octet parts, both using length prefixes. 18 While the convergence layer is intended to be used over Bluetooth, 19 any underlying protocol providing reliable transmission could 20 potentially be used. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 04, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Bluetooth Convergence Layer Specification . . . . . . . . . . 2 55 2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. PUBLISH-RESP . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. GET-RESP . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.5. SEARCH . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.6. SEARCH-RESP . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 5.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [RFC2119]. 74 2. Bluetooth Convergence Layer Specification 76 This section specifies a NetInf Convergence Layer 77 [I-D.kutscher-icnrg-netinf-proto] intended to be used over Bluetooth. 78 The protocol does not provide reliable transmission. This is assumed 79 to be provided by the underlying Bluetooth protocol, e.g. radio 80 frequency communication (RFCOMM). The Bluetooth convergence layer 81 (BCL) could potentially also be used on top of non-Bluetooth 82 protocols providing the required features (e.g. TCP). 84 The BCL does not provide any means of discovering or selecting which 85 devices to route to. This problem must be handled by the 86 implementation. A Bluetooth connection needs to be established 87 between the sender and the receiver. This connection MAY use RFCOMM 88 [RFCOMM]. It MAY be established using the service discovery protocol 89 [SDAP] with the Universally Unique IDentifier [RFC4122] 90 111a8500-6ae2-11e2-bcfd-0800200c9a66. 92 The response to a request SHOULD be sent back using the same 93 connection (if two-way communication is supported) but an 94 implementation MUST NOT assume that this always is the case. 96 The protocol is built around sending UTF-8 [RFC3629] encoded JSON and 97 NDO octets through a stream providing reliable transmission. All 98 JSON and octet parts MUST be prefixed with their length in bytes. 99 The length prefix MUST be a 32-bit signed integer encoded in two's 100 complement using big endian network byte order. 102 The ni URI scheme [RFC6920] MUST be supported. Other URI schemes MAY 103 be supported. 105 The following names are defined for JSON name/value pairs: 107 ------------------------------------------------------------------ 108 Name | Value | Comments 109 ------------------------------------------------------------------ 110 type | string | Message type. MUST be "publish", 111 | | "publish-response", "get", "get-response", 112 | | "search" or "search-response". 113 ------------------------------------------------------------------ 114 msgid | string | Message identifier. 115 ------------------------------------------------------------------ 116 uri | string | NDO URI. 117 ------------------------------------------------------------------ 118 hoplimit | number | Number of times to forward this message. 119 | | Assumed to be 0 if not present. 120 ------------------------------------------------------------------ 121 locators | [string] | Locators to the NDO. 122 ------------------------------------------------------------------ 123 ext | object | Metadata and future extensions. Metadata 124 | | MUST be an object under the "meta" key if 125 | | present. E.g. "ext":{"meta":{...}} 126 ------------------------------------------------------------------ 127 octets | true/false | Flag indicating if this JSON is directly 128 | | followed by the NDO octets (including the 129 | | length prefix). Assumed to be false if 130 | | not present. 131 ------------------------------------------------------------------ 132 status | number | Code indicating the status of a response. 133 ------------------------------------------------------------------ 134 tokens | [string] | Tokens used in a SEARCH. MUST contain at 135 | | least one token. 136 ------------------------------------------------------------------ 137 results | [object] | The results of a search. See Section 2.6. 138 ------------------------------------------------------------------ 139 Figure 1: Bluetooth CL JSON 141 2.1. PUBLISH 143 A PUBLISH MUST start with a JSON part (including the associated 144 length prefix). The JSON part MUST include the following name/value 145 pairs: 147 o type 149 o msgid 151 o uri 153 Where "type" MUST be "publish" and "uri" MUST be the URI of the NDO 154 being published. 156 The JSON part MAY also include: 158 o hoplimit 160 o locators 162 o ext 164 o octets 166 If "octets" is present and true, the JSON part MUST be followed by 167 the octets of the NDO (including the associated length prefix). If 168 "octets" is not present or false, the JSON part MUST NOT be followed 169 by the octets. 171 2.2. PUBLISH-RESP 173 A PUBLISH-RESP MUST consist of a single JSON part. The JSON part 174 MUST include the following name/value pairs: 176 o type 178 o status 180 o msgid 182 Where "type" MUST be "publish-response". 184 2.3. GET 185 A GET MUST consist of a single JSON part. The JSON part MUST include 186 the following name/value pairs: 188 o type 190 o msgid 192 o uri 194 Where "type" MUST be "get". 196 The JSON part MAY also include: 198 o hoplimit 200 2.4. GET-RESP 202 A GET-RESP MUST start with a JSON part. The JSON part MUST include 203 the following name/value pairs: 205 o type 207 o status 209 o msgid 211 o uri 213 Where "type" MUST be "get-response" and "uri" MUST be the URI 214 requested NDO. 216 The JSON part MAY also include: 218 o locators 220 o octets 222 If "octets" is present and true, the JSON part MUST be followed by 223 the octets of the requested NDO. If "octets" is not present or 224 false, the JSON part MUST NOT be followed by the octets. 226 2.5. SEARCH 228 A SEARCH MUST consist of a single JSON part. The JSON part MUST 229 include the following name/value pairs: 231 o type 232 o msgid 234 o tokens 236 Where "type" MUST be "search". 238 The JSON part MAY also include: 240 o hoplimit 242 2.6. SEARCH-RESP 244 A SEARCH-RESP MUST consist of a single JSON part. The JSON part MUST 245 include the following name/value pairs: 247 o type 249 o status 251 o msgid 253 o results 255 Where "type" MUST be "search-response". 257 Each object in the "results" array represents an NDO considered to 258 match the tokens included in the corresponding SEARCH. If no 259 matching NDOs were found "results" might be empty. The following 260 name/value pairs are defined for the search result objects: 262 ------------------------------------------------------------------ 263 Name | Value | Comments 264 ------------------------------------------------------------------ 265 ni | string | The ni URI of the matching NDO. 266 | | MUST be included. 267 ------------------------------------------------------------------ 268 metadata | object | Metadata belonging to the matching NDO. 269 | | MAY be included. 270 ------------------------------------------------------------------ 272 Figure 2: Search result JSON 274 3. Security Considerations 276 As mentioned in [I-D.kutscher-icnrg-netinf-proto] requesters SHOULD 277 attempt to limit the amount of personally identifying information for 278 privacy reasons. Care should be taken when generating SEARCH tokens 279 and when responding to a SEARCH. 281 Validation of name-data integrity is important. Consider a scenario 282 where the connected Bluetooth devices are a number of smart phones 283 that happen to be in close proximity. The other devices can not be 284 trusted to send the correct data and might even try to send malicious 285 data. 287 In the smart phone case battery life is also something to take into 288 consideration. By requesting data over and over again a requester 289 could intentionally drain the battery of the responder. 291 4. IANA Considerations 293 This document has no actions for IANA. 295 5. References 297 5.1. Normative References 299 [I-D.kutscher-icnrg-netinf-proto] 300 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 301 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 302 progress), February 2013. 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 308 10646", STD 63, RFC 3629, November 2003. 310 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 311 Keranen, A., and P. Hallam-Baker, "Naming Things with 312 Hashes", RFC 6920, April 2013. 314 5.2. Informative References 316 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 317 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 318 2005. 320 [RFCOMM] Bluetooth Special Interest Group , "RFCOMM with TS 07.10 321 Serial Port Emulation", November 2012. 323 [SDAP] Bluetooth Special Interest Group , "Service Discovery 324 Application Profile", February 2001. 326 Author's Address 328 Linus Sunde 329 Uppsala University 330 Uppsala 331 Sweden 333 Email: Linus.Sunde.9273@student.uu.se