idnits 2.17.1 draft-jennings-core-senml-06.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 (April 5, 2016) is 2914 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BIPM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST811' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-05) exists of draft-arkko-core-dev-urn-03 == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 == Outdated reference: A later version (-10) exists of draft-ietf-core-links-json-04 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track Z. Shelby 5 Expires: October 7, 2016 ARM 6 J. Arkko 7 A. Keranen 8 Ericsson 9 April 5, 2016 11 Media Types for Sensor Markup Language (SenML) 12 draft-jennings-core-senml-06 14 Abstract 16 This specification defines media types for representing simple sensor 17 measurements and device parameters in the Sensor Markup Language 18 (SenML). Representations are defined in JavaScript Object Notation 19 (JSON), Concise Binary Object Representation (CBOR), eXtensible 20 Markup Language (XML), and Efficient XML Interchange (EXI), which 21 share the common SenML data model. A simple sensor, such as a 22 temperature sensor, could use this media type in protocols such as 23 HTTP or CoAP to transport the measurements of the sensor or to be 24 configured. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 7, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Associating Meta-data . . . . . . . . . . . . . . . . . . . . 8 65 6. JSON Representation (application/senml+json) . . . . . . . . 8 66 6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 9 68 6.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 9 69 6.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 10 70 6.1.4. Collection of Resources . . . . . . . . . . . . . . . 11 71 7. CBOR Representation (application/senml+cbor) . . . . . . . . 12 72 8. XML Representation (application/senml+xml) . . . . . . . . . 13 73 9. EXI Representation (application/senml-exi) . . . . . . . . . 15 74 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 19 75 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 21 78 12.2. SenML label registry . . . . . . . . . . . . . . . . . . 24 79 12.3. Media Type Registration . . . . . . . . . . . . . . . . 24 80 12.3.1. senml+json Media Type Registration . . . . . . . . . 24 81 12.3.2. senml+cbor Media Type Registration . . . . . . . . . 25 82 12.3.3. senml+xml Media Type Registration . . . . . . . . . 26 83 12.3.4. senml-exi Media Type Registration . . . . . . . . . 27 84 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 28 85 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 28 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 87 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 88 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 89 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 16.1. Normative References . . . . . . . . . . . . . . . . . . 29 91 16.2. Informative References . . . . . . . . . . . . . . . . . 30 92 Appendix A. Links extension . . . . . . . . . . . . . . . . . . 31 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 95 1. Overview 97 Connecting sensors to the internet is not new, and there have been 98 many protocols designed to facilitate it. This specification defines 99 new media types for carrying simple sensor information in a protocol 100 such as HTTP or CoAP called the Sensor Markup Language (SenML). This 101 format was designed so that processors with very limited capabilities 102 could easily encode a sensor measurement into the media type, while 103 at the same time a server parsing the data could relatively 104 efficiently collect a large number of sensor measurements. The 105 markup language can be used for a variety of data flow models, most 106 notably data feeds pushed from a sensor to a collector, and the web 107 resource model where the sensor is requested as a resource 108 representation (e.g., "GET /sensor/temperature"). 110 There are many types of more complex measurements and measurements 111 that this media type would not be suitable for. SenML strikes a 112 balance between having some information about the sensor carried with 113 the sensor data so that the data is self describing but it also tries 114 to make that a fairly minimal set of auxiliary information for 115 efficiency reason. Other information about the sensor can be 116 discovered by other methods such as using the CoRE Link Format 117 [RFC6690]. 119 SenML is defined by a data model for measurements and simple meta- 120 data about measurements and devices. The data is structured as a 121 single array that contains a series of SenML Records which can each 122 contain attributes such as an unique identifier for the sensor, the 123 time the measurement was made, the unit the measurement is in, and 124 the current value of the sensor. Serializations for this data model 125 are defined for JSON [RFC7159], CBOR [RFC7049], XML, and Efficient 126 XML Interchange (EXI) [W3C.REC-exi-20110310]. 128 For example, the following shows a measurement from a temperature 129 gauge encoded in the JSON syntax. 131 [{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }] 133 In the example above, the array has a single SenML Record with a 134 measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a 135 current value of 23.5 degrees Celsius. 137 2. Requirements and Design Goals 139 The design goal is to be able to send simple sensor measurements in 140 small packets on mesh networks from large numbers of constrained 141 devices. Keeping the total size of payload under 80 bytes makes this 142 easy to use on a wireless mesh network. It is always difficult to 143 define what small code is, but there is a desire to be able to 144 implement this in roughly 1 KB of flash on a 8 bit microprocessor. 145 Experience with Google power meter and large scale deployments has 146 indicated that the solution needs to support allowing multiple 147 measurements to be batched into a single HTTP or CoAP request. This 148 "batch" upload capability allows the server side to efficiently 149 support a large number of devices. It also conveniently supports 150 batch transfers from proxies and storage devices, even in situations 151 where the sensor itself sends just a single data item at a time. The 152 multiple measurements could be from multiple related sensors or from 153 the same sensor but at different times. 155 The basic design is an array with a series of measurements. The 156 following example shows two measurements made at different times. 157 The value of a measurement is in the "v" tag, the time of a 158 measurement is in the "t" tag, the "n" tag has a unique sensor name, 159 and the unit of the measurement is carried in the "u" tag. 161 [ 162 { "n": "urn:dev:ow:10e2073a01080063", 163 "t": 1276020076, "v":23.5, "u":"Cel" }, 164 { "n": "urn:dev:ow:10e2073a01080063", 165 "t": 1276020091, "v":23.6, "u":"Cel" } 166 ] 168 To keep the messages small, it does not make sense to repeat the "n" 169 tag in each SenML Record so there is a concept of a Base Name which 170 is simply a string that is prepended to the Name field of all 171 elements in that record and any records that follow it. So a more 172 compact form of the example above is the following. 174 [ 175 { "bn": "urn:dev:ow:10e2073a01080063", 176 "t": 1276020076, "v":23.5, "u":"Cel" }, 177 { "t": 1276020091, "v":23.6, "u":"Cel" } 178 ] 180 In the above example the Base Name is in the "bn" tag and the "n" 181 tags in each Record are the empty string so they are omitted. The 182 Base Name also could be put in a separate Record such as in the 183 following example. 185 [ 186 { "bn": "urn:dev:ow:10e2073a01080063" }, 187 { "t": 1276020076, "v":23.5, "u":"Cel" }, 188 { "t": 1276020091, "v":23.6, "u":"Cel" } 189 ] 190 Some devices have accurate time while others do not so SenML supports 191 absolute and relative times. Time is represented in floating point 192 as seconds and values greater than zero represent an absolute time 193 relative to the unix epoch while values of 0 or less represent a 194 relative time in the past from the current time. A simple sensor 195 with no absolute wall clock time might take a measurement every 196 second and batch up 60 of them then send it to a server. It would 197 include the relative time the measurement was made to the time the 198 batch was send in the SenML Pack. The server might have accurate NTP 199 time and use the time it received the data, and the relative offset, 200 to replace the times in the SenML with absolute times before saving 201 the SenML Pack in a document database. 203 3. Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 207 "OPTIONAL" in this document are to be interpreted as described in 208 [RFC2119]. 210 This document also uses the following terms: 212 SenML Record: One measurement or configuration instance in time 213 presented using the SenML data model. 215 SenML Pack: One or more SenML Records in an array structure. 217 4. Semantics 219 Each SenML Pack carries a single array that represents a set of 220 measurements and/or parameters. This array contains a series of 221 objects with several optional attributes described below: 223 Base Name: This is a string that is prepended to the names found in 224 the entries. This attribute is optional. This applies to the 225 entries in all Records. A Base Name can only be included in the 226 first Record of the array. 228 Base Time: A base time that is added to the time found in an entry. 229 This attribute is optional. This applies to the entries in all 230 Records. A Base Time can only be included in the first Record of 231 the array. 233 Base Unit: A base unit that is assumed for all entries, unless 234 otherwise indicated. This attribute is optional. If a record 235 does not contain a unit value, then the base unit is used 236 otherwise the value of found in the Unit is used. This applies to 237 the entries in all Records. A Base Unit can only be included in 238 the first object of the array. 240 Base Value: A base value is added to the value found in an entry, 241 similar to Base Time. This attribute is optional. This applies 242 to the entries in all Records. A Base Value can only be included 243 in the first Record of the array. 245 Version: Version number of media type format. This attribute is 246 optional positive integer and defaults to 5 if not present. A 247 Version can only be included in the first object of the array. 249 Name: Name of the sensor or parameter. When appended to the Base 250 Name attribute, this must result in a globally unique identifier 251 for the resource. The name is optional, if the Base Name is 252 present. If the name is missing, Base Name must uniquely identify 253 the resource. This can be used to represent a large array of 254 measurements from the same sensor without having to repeat its 255 identifier on every measurement. 257 Unit: Units for a measurement value. Optional. If the Record has 258 not Unit, the Base Unit is used as the Unit. Having no Unit and 259 no Base Unit is allowed. 261 Value Value of the entry. Optional if a Sum value is present, 262 otherwise required. Values are represented using three basic data 263 types, Floating point numbers ("v" field for "Value"), Booleans 264 ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and 265 Data ("vd" for "Binary Data Value") . Exactly one of these three 266 fields MUST appear unless there is Sum field in which case it is 267 allowed to have no Value field or to have "v" field. 269 Sum: Integrated sum of the values over time. Optional. This 270 attribute is in the units specified in the Unit value multiplied 271 by seconds. 273 Time: Time when value was recorded. Optional. 275 Update Time: An optional time in seconds that represents the maximum 276 time before this sensor will provide an updated reading for a 277 measurement. This can be used to detect the failure of sensors or 278 communications path from the sensor. 280 The SenML format can be extended with further custom attributes. 281 TODO - describe what extensions are possible and how to do them. 283 Systems reading one of the objects MUST check for the Version 284 attribute. If this value is a version number larger than the version 285 which the system understands, the system SHOULD NOT use this object. 286 This allows the version number to indicate that the object contains 287 mandatory to understand attributes. New version numbers can only be 288 defined in an RFC that updates this specification or it successors. 290 The Name value is concatenated to the Base Name value to get the name 291 of the sensor. The resulting name needs to uniquely identify and 292 differentiate the sensor from all others. If the object is a 293 representation resulting from the request of a URI [RFC3986], then in 294 the absence of the Base Name attribute, this URI is used as the 295 default value of Base Name. Thus in this case the Name field needs 296 to be unique for that URI, for example an index or subresource name 297 of sensors handled by the URI. 299 Alternatively, for objects not related to a URI, a unique name is 300 required. In any case, it is RECOMMENDED that the full names are 301 represented as URIs or URNs [RFC2141]. One way to create a unique 302 name is to include some bit string that has guaranteed uniqueness 303 (such as a 1-wire address) that is assigned to the device. Some of 304 the examples in this draft use the device URN type as specified in 305 [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to 306 generate a unique name. Note that long-term stable unique 307 identifiers are problematic for privacy reasons [RFC7721] and should 308 be used with care or avoided. 310 The resulting concatenated name MUST consist only of characters out 311 of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 312 and it MUST start with a character out of the set "A" to "Z", "a" to 313 "z", or "0" to "9". This restricted character set was chosen so that 314 these names can be directly used as in other types of URI including 315 segments of an HTTP path with no special encoding and can be directly 316 used in many databases and analytic systems. [RFC5952] contains 317 advice on encoding an IPv6 address in a name. 319 If either the Base Time or Time value is missing, the missing 320 attribute is considered to have a value of zero. The Base Time and 321 Time values are added together to get the time of measurement. A 322 time of zero indicates that the sensor does not know the absolute 323 time and the measurement was made roughly "now". A negative value is 324 used to indicate seconds in the past from roughly "now". A positive 325 value is used to indicate the number of seconds, excluding leap 326 seconds, since the start of the year 1970 in UTC. 328 Representing the statistical characteristics of measurements, such as 329 accuracy, can be very complex. Future specification may add new 330 attributes to provide better information about the statistical 331 properties of the measurement. 333 5. Associating Meta-data 335 SenML is designed to carry the minimum dynamic information about 336 measurements, and for efficiency reasons does not carry significant 337 static meta-data about the device, object or sensors. Instead, it is 338 assumed that this meta-data is carried out of band. For web 339 resources using SenML Packs, this meta-data can be made available 340 using the CoRE Link Format [RFC6690]. The most obvious use of this 341 link format is to describe that a resource is available in a SenML 342 format in the first place. The relevant media type indicator is 343 included in the Content-Type (ct=) attribute. 345 6. JSON Representation (application/senml+json) 347 Record atributes: 349 +---------------+------+---------+ 350 | SenML | JSON | Type | 351 +---------------+------+---------+ 352 | Base Name | bn | String | 353 | Base Time | bt | Number | 354 | Base Unit | bu | String | 355 | Base Value | bv | Number | 356 | Version | bver | Number | 357 | Name | n | String | 358 | Unit | u | String | 359 | Value | v | Number | 360 | String Value | vs | String | 361 | Boolean Value | vb | Boolean | 362 | Data Value | vd | String | 363 | Value Sum | s | Number | 364 | Time | t | Number | 365 | Update Time | ut | Number | 366 +---------------+------+---------+ 368 The root content consists of an array with JSON objects for each 369 SenML Record. All the fields in the above table MAY occur in the 370 records with the type specified in the table. 372 Only the UTF-8 form of JSON is allowed. Characters in the String 373 Value are encoded using the escape sequences defined in [RFC4627]. 374 Characters in the Data Value are base64 encoded with URL safe 375 alphabet as defined in Section 5 of [RFC4648]. 377 Systems receiving measurements MUST be able to process the range of 378 floating point numbers that are representable as an IEEE double- 379 precision floating-point numbers [IEEE.754.1985]. The number of 380 significant digits in any measurement is not relevant, so a reading 381 of 1.1 has exactly the same semantic meaning as 1.10. If the value 382 has an exponent, the "e" MUST be in lower case. The mantissa SHOULD 383 be less than 19 characters long and the exponent SHOULD be less than 384 5 characters long. This allows time values to have better than micro 385 second precision over the next 100 years. 387 6.1. Examples 389 TODO - simplify examples 391 TODO - Examples are messed up on if time is an integer or float 393 TODO - Add example with string, data, boolean, and base value 395 6.1.1. Single Datapoint 397 The following shows a temperature reading taken approximately "now" 398 by a 1-wire sensor device that was assigned the unique 1-wire address 399 of 10e2073a01080063: 401 [{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }] 403 6.1.2. Multiple Datapoints 405 The following example shows voltage and current now, i.e., at an 406 unspecified time. 408 [{"bn": "urn:dev:ow:10e2073a01080063/"}, 409 { "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, 410 { "n": "current", "t": 0, "u": "A", "v": 1.2 } 411 ] 413 The next example is similar to the above one, but shows current at 414 Tue Jun 8 18:01:16 UTC 2010 and at each second for the previous 5 415 seconds. 417 [{"bn": "urn:dev:ow:10e2073a01080063/", 418 "bt": 1276020076.001, 419 "bu": "A", 420 "bver": 5}, 421 { "n": "voltage", "u": "V", "v": 120.1 }, 422 { "n": "current", "t": -5, "v": 1.2 }, 423 { "n": "current", "t": -4, "v": 1.30 }, 424 { "n": "current", "t": -3, "v": 0.14e1 }, 425 { "n": "current", "t": -2, "v": 1.5 }, 426 { "n": "current", "t": -1, "v": 1.6 }, 427 { "n": "current", "t": 0, "v": 1.7 } 428 ] 429 Note that in some usage scenarios of SenML the implementations MAY 430 store or transmit SenML in a stream-like fashion, where data is 431 collected over time and continuously added to the object. This mode 432 of operation is optional, but systems or protocols using SenML in 433 this fashion MUST specify that they are doing this. SenML defines a 434 separate mime type (TODO) to indicate Sensor Streaming Markup 435 Language (SensML) for this usage. In this situation the SensML 436 stream can be sent and received in a partial fashion, i.e., a 437 measurement entry can be read as soon as the SenML Record is received 438 and not have to wait for the full SensML Stream to be complete. 440 For instance, the following stream of measurements may be sent via a 441 long lived HTTP POST from the producer of a SensML to the consumer of 442 that, and each measurement object may be reported at the time it 443 measured: 445 [ {"bn": "urn:dev:ow:10e2073a01080063", 446 "bt": 1320067464, 447 "bu": "%RH"}, 448 { "v": 21.2, "t": 0 }, 449 { "v": 21.3, "t": 10 }, 450 { "v": 21.4, "t": 20 }, 451 { "v": 21.4, "t": 30 }, 452 { "v": 21.5, "t": 40 }, 453 { "v": 21.5, "t": 50 }, 454 { "v": 21.5, "t": 60 }, 455 { "v": 21.6, "t": 70 }, 456 { "v": 21.7, "t": 80 }, 457 { "v": 21.5, "t": 90 }, 458 ... 460 6.1.3. Multiple Measurements 462 The following example shows humidity measurements from a mobile 463 device with an IPv6 address 2001:db8::1, starting at Mon Oct 31 464 13:24:24 UTC 2011. The device also provides position data, which is 465 provided in the same measurement or parameter array as separate 466 entries. Note time is used to for correlating data that belongs 467 together, e.g., a measurement and a parameter associated with it. 468 Finally, the device also reports extra data about its battery status 469 at a separate time. 471 [{"bn": "urn:dev:ow:10e2073a01080063", 472 "bt": 1320067464, 473 "bu": "%RH"}, 474 { "v": 20.0, "t": 0 }, 475 { "v": 24.30621, "u": "lon", "t": 0 }, 476 { "v": 60.07965, "u": "lat", "t": 0 }, 477 { "v": 20.3, "t": 60 }, 478 { "v": 24.30622, "u": "lon", "t": 60 }, 479 { "v": 60.07965, "u": "lat", "t": 60 }, 480 { "v": 20.7, "t": 120 }, 481 { "v": 24.30623, "u": "lon", "t": 120 }, 482 { "v": 60.07966, "u": "lat", "t": 120 }, 483 { "v": 98.0, "u": "%EL", "t": 150 }, 484 { "v": 21.2, "t": 180 }, 485 { "v": 24.30628, "u": "lon", "t": 180 }, 486 { "v": 60.07967, "u": "lat", "t": 180 } 487 ] 489 The size of this example represented in various forms, as well as 490 that form compressed with gzip is given in the following table. 492 +----------+------+-----------------+ 493 | Encoding | Size | Compressed Size | 494 +----------+------+-----------------+ 495 | JSON | 567 | 200 | 496 | XML | 656 | 232 | 497 | CBOR | 292 | 192 | 498 | EXI | 160 | 183 | 499 +----------+------+-----------------+ 501 Table 1: Size Comparisons 503 Note the CBOR and EXI sizes are not using the schema guidance so the 504 could be a bit smaller. 506 6.1.4. Collection of Resources 508 The following example shows how to query one device that can provide 509 multiple measurements. The example assumes that a client has fetched 510 information from a device at 2001:db8::2 by performing a GET 511 operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, 512 and has gotten two separate values as a result, a temperature and 513 humidity measurement. 515 [{"bn": "urn:dev:ow:10e2073a01080063/", 516 "bt": 1320078429, 517 "bver": 5 518 }, 519 { "n": "temperature", "v": 27.2, "u": "Cel" }, 520 { "n": "humidity", "v": 80, "u": "%RH" } 521 ] 523 7. CBOR Representation (application/senml+cbor) 525 The CBOR [RFC7049] representation is equivalent to the JSON 526 representation, with the following changes: 528 o For compactness, the CBOR representation uses integers for the map 529 keys defined in Table 2. This table is conclusive, i.e., there is 530 no intention to define any additional integer map keys; any 531 extensions will use string map keys. 533 o For JSON Numbers, the CBOR representation can use integers, 534 floating point numbers, or decimal fractions (CBOR Tag 4); the 535 common limitations of JSON implementations are not relevant for 536 these. For the version number, however, only an unsigned integer 537 is allowed. 539 +---------------+------------+------------+ 540 | Name | JSON label | CBOR label | 541 +---------------+------------+------------+ 542 | Version | bver | -1 | 543 | Base Name | bn | -2 | 544 | Base Time | bt | -3 | 545 | Base Units | bu | -4 | 546 | Base Value | bv | -5 | 547 | Name | n | 0 | 548 | Units | u | 1 | 549 | Value | v | 2 | 550 | String Value | vs | 3 | 551 | Boolean Value | vb | 4 | 552 | Value Sum | s | 5 | 553 | Time | t | 6 | 554 | Update Time | ut | 7 | 555 | Data Value | vd | 8 | 556 +---------------+------------+------------+ 558 Table 2: CBOR representation: integers for map keys 560 The following example shows an hexdump of the CBOR example for the 561 same sensor measurement as in Section 6.1.2. 563 0000 88 a4 62 62 6e 78 1c 75 72 6e 3a 64 65 76 3a 6f |..bbnx.urn:dev:o| 564 0010 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 30 30 |w:10e2073a010800| 565 0020 36 33 2f 62 62 74 1a 4c 0e 85 6c 62 62 75 61 41 |63/bbt.L..lbbuaA| 566 0030 63 76 65 72 05 a3 61 6e 67 76 6f 6c 74 61 67 65 |cver..angvoltage| 567 0040 61 75 61 56 61 76 fb 40 5e 06 66 66 66 66 66 a3 |auaVav.@^.fffff.| 568 0050 61 6e 67 63 75 72 72 65 6e 74 61 74 24 61 76 fb |angcurrentat$av.| 569 0060 3f f3 33 33 33 33 33 33 a3 61 6e 67 63 75 72 72 |?.333333.angcurr| 570 0070 65 6e 74 61 74 23 61 76 fb 3f f4 cc cc cc cc cc |entat#av.?......| 571 0080 cd a3 61 6e 67 63 75 72 72 65 6e 74 61 74 22 61 |..angcurrentat"a| 572 0090 76 fb 3f f6 66 66 66 66 66 66 a3 61 6e 67 63 75 |v.?.ffffff.angcu| 573 00a0 72 72 65 6e 74 61 74 21 61 76 fb 3f f8 00 00 00 |rrentat!av.?....| 574 00b0 00 00 00 a3 61 6e 67 63 75 72 72 65 6e 74 61 74 |....angcurrentat| 575 00c0 20 61 76 fb 3f f9 99 99 99 99 99 9a a2 61 6e 67 | av.?........ang| 576 00d0 63 75 72 72 65 6e 74 61 76 fb 3f fb 33 33 33 33 |currentav.?.3333| 577 00e0 33 33 0a |33.| 578 00e3 580 8. XML Representation (application/senml+xml) 582 A SenML Stream can also be represented in XML format as defined in 583 this section. The following example shows an XML example for the 584 same sensor measurement as in Section 6.1.2. 586 587 589 590 591 592 593 594 595 596 598 The SenML Stream is represented as a sensml tag that contains a 599 series of senml tags for each SenML Record. The SenML Fields are 600 represents as XML attributes. The following table shows the mapping 601 the SenML Field names to the attribute used in the XML senml tag. 603 +---------------+------+---------+ 604 | SenML Field | XML | Type | 605 +---------------+------+---------+ 606 | Base Name | bn | string | 607 | Base Time | bt | float | 608 | Base Unit | bu | string | 609 | Base Value | bv | float | 610 | Version | bver | int | 611 | Name | n | string | 612 | Unit | u | string | 613 | Value | v | float | 614 | String Value | vs | string | 615 | Data Value | vd | string | 616 | Boolean Value | vb | boolean | 617 | Value Sum | s | float | 618 | Time | t | float | 619 | Update Time | ut | float | 620 +---------------+------+---------+ 622 The RelaxNG schema for the XML is: 624 default namespace = "urn:ietf:params:xml:ns:senml" 625 namespace rng = "http://relaxng.org/ns/structure/1.0" 627 link = element l { 628 attribute * { xsd:string }* 629 } 631 senml = element senml { 632 attribute bn { xsd:string }?, 633 attribute bt { xsd:double }?, 634 attribute bv { xsd:double }?, 635 attribute bu { xsd:string }?, 636 attribute bver { xsd:int }?, 638 attribute n { xsd:string }?, 639 attribute s { xsd:double }?, 640 attribute t { xsd:double }?, 641 attribute u { xsd:string }?, 642 attribute ut { xsd:double }?, 644 attribute v { xsd:double }?, 645 attribute vb { xsd:boolean }?, 646 attribute vs { xsd:string }?, 647 attribute vd { xsd:string }?, 649 link* 650 } 652 sensml = 653 element sensml { 654 senml+ 655 } 657 start = sensml 659 9. EXI Representation (application/senml-exi) 661 For efficient transmission of SenML over e.g. a constrained network, 662 Efficient XML Interchange (EXI) can be used. This encodes the XML 663 Schema structure of SenML into binary tags and values rather than 664 ASCII text. An EXI representation of SenML SHOULD be made using the 665 strict schema-mode of EXI. This mode however does not allow tag 666 extensions to the schema, and therefore any extensions will be lost 667 in the encoding. For uses where extensions need to be preserved in 668 EXI, the non-strict schema mode of EXI MAY be used. 670 The EXI header option MUST be included. An EXI schemaID options MUST 671 be set to the value of "a" indicating the scheme provided in this 672 specification. Future revisions to the schema can change this 673 schemaID to allow for backwards compatibility. When the data will be 674 transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it 675 simply makes things larger and is redundant to information provided 676 in the Content-Type header. 678 TODO - examples probably have the wrong setting the schemaID 680 The following is the XSD Schema to be used for strict schema guided 681 EXI processing. It is generated from the RelaxNG. 683 684 688 689 690 691 692 693 694 695 696 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 724 The following shows a hexdump of the EXI produced from encoding the 725 following XML example. Note this example is the same information as 726 the first example in Section 6.1.2 in JSON format. 728 729 730 731 732 734 Which compresses with EXI to the following displayed in hexdump: 736 0000 a0 30 41 cd 95 b9 b5 b0 d4 b9 9d 95 b8 b9 e1 cd |.0A.............| 737 0010 91 00 f3 ab 93 71 d3 23 2b b1 d3 7b b9 d1 89 83 |.....q.#+..{....| 738 0020 29 91 81 b9 9b 09 81 89 81 c1 81 81 b1 99 7f 14 |)...............| 739 0030 25 d9 bd b1 d1 85 9d 94 80 d5 8a c4 26 01 0a 12 |%...........&...| 740 0040 c6 ea e4 e4 ca dc e8 40 68 24 19 00 90 |.......@h$...| 741 004d 743 The above example used the bit packed form of EXI but it is also 744 possible to use a byte packed form of EXI which can makes it easier 745 for a simple sensor to produce valid EXI without really implementing 746 EXI. Consider the example of a temperature sensor that produces a 747 value in tenths of degrees Celsius over a range of 0.0 to 55.0. It 748 would produce an XML SenML file such as: 750 751 752 754 The compressed form, using the byte alignment option of EXI, for the 755 above XML is the following: 757 0000 a0 00 48 82 0e 6c ad cd ad 86 a5 cc ec ad c5 cf |..H..l..........| 758 0010 0e 6c 80 02 05 1d 75 72 6e 3a 64 65 76 3a 6f 77 |.l....urn:dev:ow| 759 0020 3a 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 |:10e2073a0108006| 760 0030 33 02 05 43 65 6c 01 00 e7 01 01 00 04 01 |3..Cel........| 761 003e 763 A small temperature sensor devices that only generates this one EXI 764 file does not really need an full EXI implementation. It can simple 765 hard code the output replacing the one wire device ID starting at 766 byte 0x16 and going to byte 0x31 with it's device ID, and replacing 767 the value "0xe7 0x01" at location 0x38 to 0x39 with the current 768 temperature. The EXI Specification [W3C.REC-exi-20110310] contains 769 the full information 'on how floating point numbers are represented, 770 but for the purpose of this sensor, the temperature can be converted 771 to an integer in tenths of degrees (231 in this example). EXI stores 772 7 bits of the integer in each byte with the top bit set to one if 773 there are further bytes. So the first bytes at is set to low 7 bits 774 of the integer temperature in tenths of degrees plus 0x80. In this 775 example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the 776 integer temperature in tenths of degrees right shifted 7 bits. In 777 this example 231 >> 7 = 0x01. 779 10. Usage Considerations 781 The measurements support sending both the current value of a sensor 782 as well as the an integrated sum. For many types of measurements, 783 the sum is more useful than the current value. For example, an 784 electrical meter that measures the energy a given computer uses will 785 typically want to measure the cumulative amount of energy used. This 786 is less prone to error than reporting the power each second and 787 trying to have something on the server side sum together all the 788 power measurements. If the network between the sensor and the meter 789 goes down over some period of time, when it comes back up, the 790 cumulative sum helps reflect what happened while the network was 791 down. A meter like this would typically report a measurement with 792 the units set to watts, but it would put the sum of energy used in 793 the "s" attribute of the measurement. It might optionally include 794 the current power in the "v" attribute. 796 While the benefit of using the integrated sum is fairly clear for 797 measurements like power and energy, it is less obvious for something 798 like temperature. Reporting the sum of the temperature makes it easy 799 to compute averages even when the individual temperature values are 800 not reported frequently enough to compute accurate averages. 801 Implementors are encouraged to report the cumulative sum as well as 802 the raw value of a given sensor. 804 Applications that use the cumulative sum values need to understand 805 they are very loosely defined by this specification, and depending on 806 the particular sensor implementation may behave in unexpected ways. 807 Applications should be able to deal with the following issues: 809 1. Many sensors will allow the cumulative sums to "wrap" back to 810 zero after the value gets sufficiently large. 812 2. Some sensors will reset the cumulative sum back to zero when the 813 device is reset, loses power, or is replaced with a different 814 sensor. 816 3. Applications cannot make assumptions about when the device 817 started accumulating values into the sum. 819 Typically applications can make some assumptions about specific 820 sensors that will allow them to deal with these problems. A common 821 assumption is that for sensors whose measurement values are always 822 positive, the sum should never get smaller; so if the sum does get 823 smaller, the application will know that one of the situations listed 824 above has happened. 826 11. CDDL 828 For reference, the CBOR representation can be described with the CDDL 829 [I-D.greevenbosch-appsawg-cbor-cddl] specification in Figure 1. 831 SenML-Pack = [initial-record, * follow-on-record] 833 initial-record = initial-defined .and initial-generic 834 follow-on-record = follow-on-defined .and follow-on-generic 836 ; first do a specification of the labels as defined: 838 initial-defined = { 839 ? bn => tstr, ; Base Name 840 ? bt => numeric, ; Base Time 841 ? bu => tstr, ; Base Units 842 ? bv => numeric, ; Base value 843 ? bver => uint, ; Base Version 844 follow-on-defined-group, 845 + base-key-value-pair 846 } 848 follow-on-defined-group = ( 849 ? n => tstr, ; Name 850 ? u => tstr, ; Units 851 ? ( v => numeric // ; Numeric Value 852 vs => tstr // ; String Value 853 vb => bool // ; Boolean Value 854 vd => bstr ) ; Data Value 855 ? s => numeric, ; Value Sum 856 ? t => numeric, ; Time 857 ? ut => numeric, ; Update Time 858 * key-value-pair 859 ) 860 follow-on-defined = { follow-on-defined-group } 862 ; CBOR version (use the labels) 863 bver = -1 n = 0 s = 5 864 bn = -2 u = 1 t = 6 865 bt = -3 v = 2 ut = 7 866 bu = -4 vs = 3 vd = 8 867 bv = -5 vb = 4 868 ; use the label *names* for JSON 870 ; now define the generic versions 871 initial-generic = { 872 follow-on-generic-group, 873 * base-key-value-pair, 874 } 876 follow-on-generic-group = ( 877 + key-value-pair, 878 ) 879 follow-on-generic = { follow-on-generic-group } 881 key-value-pair = ( non-b-label => value ) 883 base-key-value-pair = ( b-label => value ) 885 non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint 886 b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint 888 value = tstr / bstr / numeric / bool 889 numeric = number / decfrac 891 Figure 1: CDDL specification for CBOR SenML 893 12. IANA Considerations 895 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 896 the RFC number of this specification. 898 12.1. Units Registry 900 IANA will create a registry of SenML unit symbols. The primary 901 purpose of this registry is to make sure that symbols uniquely map to 902 give type of measurement. Definitions for many of these units can be 903 found in location such as [NIST811] and [BIPM]. 905 +--------+--------------------------------------+-------+-----------+ 906 | Symbol | Description | Type | Reference | 907 +--------+--------------------------------------+-------+-----------+ 908 | m | meter | float | RFC-AAAA | 909 | g | gram | float | RFC-AAAA | 910 | s | second | float | RFC-AAAA | 911 | A | ampere | float | RFC-AAAA | 912 | K | kelvin | float | RFC-AAAA | 913 | cd | candela | float | RFC-AAAA | 914 | mol | mole | float | RFC-AAAA | 915 | Hz | hertz | float | RFC-AAAA | 916 | rad | radian | float | RFC-AAAA | 917 | sr | steradian | float | RFC-AAAA | 918 | N | newton | float | RFC-AAAA | 919 | Pa | pascal | float | RFC-AAAA | 920 | J | joule | float | RFC-AAAA | 921 | W | watt | float | RFC-AAAA | 922 | C | coulomb | float | RFC-AAAA | 923 | V | volt | float | RFC-AAAA | 924 | F | farad | float | RFC-AAAA | 925 | Ohm | ohm | float | RFC-AAAA | 926 | S | siemens | float | RFC-AAAA | 927 | Wb | weber | float | RFC-AAAA | 928 | T | tesla | float | RFC-AAAA | 929 | H | henry | float | RFC-AAAA | 930 | Cel | degrees Celsius | float | RFC-AAAA | 931 | lm | lumen | float | RFC-AAAA | 932 | lx | lux | float | RFC-AAAA | 933 | Bq | becquerel | float | RFC-AAAA | 934 | Gy | gray | float | RFC-AAAA | 935 | Sv | sievert | float | RFC-AAAA | 936 | kat | katal | float | RFC-AAAA | 937 | pH | pH acidity | float | RFC-AAAA | 938 | % | Value of a switch (note 1) | float | RFC-AAAA | 939 | count | counter value | float | RFC-AAAA | 940 | %RH | Relative Humidity | float | RFC-AAAA | 941 | m2 | area | float | RFC-AAAA | 942 | l | volume in liters | float | RFC-AAAA | 943 | m/s | velocity | float | RFC-AAAA | 944 | m/s2 | acceleration | float | RFC-AAAA | 945 | l/s | flow rate in liters per second | float | RFC-AAAA | 946 | W/m2 | irradiance | float | RFC-AAAA | 947 | cd/m2 | luminance | float | RFC-AAAA | 948 | Bspl | bel sound pressure level | float | RFC-AAAA | 949 | bit/s | bits per second | float | RFC-AAAA | 950 | lat | degrees latitude (note 2) | float | RFC-AAAA | 951 | lon | degrees longitude (note 2) | float | RFC-AAAA | 952 | %EL | remaining battery energy level in | float | RFC-AAAA | 953 | | percents | | | 954 | EL | remaining battery energy level in | float | RFC-AAAA | 955 | | seconds | | | 956 | beat/m | Heart rate in beats per minute | float | RFC-AAAA | 957 | beats | Cumulative number of heart beats | float | RFC-AAAA | 958 +--------+--------------------------------------+-------+-----------+ 960 Table 3 962 o Note 1: A value of 0.0 indicates the switch is off while 1.0 963 indicates on and 0.5 would be half on. 965 o Note 2: Assumed to be in WGS84 unless another reference frame is 966 known for the sensor. 968 New entries can be added to the registration by either Expert Review 969 or IESG Approval as defined in [RFC5226]. Experts should exercise 970 their own good judgment but need to consider the following 971 guidelines: 973 1. There needs to be a real and compelling use for any new unit to 974 be added. 976 2. Units should define the semantic information and be chosen 977 carefully. Implementors need to remember that the same word may 978 be used in different real-life contexts. For example, degrees 979 when measuring latitude have no semantic relation to degrees 980 when measuring temperature; thus two different units are needed. 982 3. These measurements are produced by computers for consumption by 983 computers. The principle is that conversion has to be easily be 984 done when both reading and writing the media type. The value of 985 a single canonical representation outweighs the convenience of 986 easy human representations or loss of precision in a conversion. 988 4. Use of SI prefixes such as "k" before the unit is not allowed. 989 Instead one can represent the value using scientific notation 990 such a 1.2e3. TODO - Open Issue. Some people would like to 991 have SI prefixes to improve human readability. 993 5. For a given type of measurement, there will only be one unit 994 type defined. So for length, meters are defined and other 995 lengths such as mile, foot, light year are not allowed. For 996 most cases, the SI unit is preferred. 998 6. Symbol names that could be easily confused with existing common 999 units or units combined with prefixes should be avoided. For 1000 example, selecting a unit name of "mph" to indicate something 1001 that had nothing to do with velocity would be a bad choice, as 1002 "mph" is commonly used to mean miles per hour. 1004 7. The following should not be used because the are common SI 1005 prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, 1006 y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 1008 8. The following units should not be used as they are commonly used 1009 to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 1010 Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 1011 BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 1013 9. The unit names are case sensitive and the correct case needs to 1014 be used, but symbols that differ only in case should not be 1015 allocated. 1017 10. A number after a unit typically indicates the previous unit 1018 raised to that power, and the / indicates that the units that 1019 follow are the reciprocal. A unit should have only one / in the 1020 name. 1022 11. A good list of common units can be found in the Unified Code for 1023 Units of Measure [UCUM]. 1025 12.2. SenML label registry 1027 IANA will create a registry for SenML labels. The initial content of 1028 the registry are shown in TODO. 1030 New entries can be added to the registration by either Expert Review 1031 or IESG Approval as defined in [RFC5226]. Experts should exercise 1032 their own good judgment but need to consider that shorter labels 1033 should have more strict review. 1035 12.3. Media Type Registration 1037 The following registrations are done following the procedure 1038 specified in [RFC6838] and [RFC7303]. 1040 12.3.1. senml+json Media Type Registration 1042 Type name: application 1044 Subtype name: senml+json and sensml+json 1046 Required parameters: none 1048 Optional parameters: none 1050 Encoding considerations: Must be encoded as using a subset of the 1051 encoding allowed in [RFC7159]. See RFC-AAAA for details. This 1052 simplifies implementation of very simple system and does not impose 1053 any significant limitations as all this data is meant for machine to 1054 machine communications and is not meant to be human readable. 1056 Security considerations: Sensor data can contain a wide range of 1057 information ranging from information that is very public, such the 1058 outside temperature in a given city, to very private information that 1059 requires integrity and confidentiality protection, such as patient 1060 health information. This format does not provide any security and 1061 instead relies on the transport protocol that carries it to provide 1062 security. Given applications need to look at the overall context of 1063 how this media type will be used to decide if the security is 1064 adequate. 1066 Interoperability considerations: Applications should ignore any JSON 1067 key value pairs that they do not understand. This allows backwards 1068 compatibility extensions to this specification. The "ver" field can 1069 be used to ensure the receiver supports a minimal level of 1070 functionality needed by the creator of the JSON object. 1072 Published specification: RFC-AAAA 1074 Applications that use this media type: The type is used by systems 1075 that report electrical power usage and environmental information such 1076 as temperature and humidity. It can be used for a wide range of 1077 sensor reporting systems. 1079 Additional information: 1081 Magic number(s): none 1083 File extension(s): senml 1085 Macintosh file type code(s): none 1087 Person & email address to contact for further information: Cullen 1088 Jennings 1090 Intended usage: COMMON 1092 Restrictions on usage: None 1094 Author: Cullen Jennings 1096 Change controller: IESG 1098 12.3.2. senml+cbor Media Type Registration 1100 Type name: application 1102 Subtype name: senml+cbor 1104 Required parameters: none 1106 Optional parameters: none 1108 Encoding considerations: TBD 1109 Security considerations: TBD 1111 Interoperability considerations: TBD 1113 Published specification: RFC-AAAA 1115 Applications that use this media type: The type is used by systems 1116 that report electrical power usage and environmental information such 1117 as temperature and humidity. It can be used for a wide range of 1118 sensor reporting systems. 1120 Additional information: 1122 Magic number(s): none 1124 File extension(s): senml 1126 Macintosh file type code(s): none 1128 Person & email address to contact for further information: Cullen 1129 Jennings 1131 Intended usage: COMMON 1133 Restrictions on usage: None 1135 Author: Cullen Jennings 1137 Change controller: IESG 1139 12.3.3. senml+xml Media Type Registration 1141 Type name: application 1143 Subtype name: senml+xml and sensml+xml 1145 Required parameters: none 1147 Optional parameters: none 1149 Encoding considerations: TBD 1151 Security considerations: TBD 1153 Interoperability considerations: TBD 1155 Published specification: RFC-AAAA 1156 Applications that use this media type: TBD 1158 Additional information: 1160 Magic number(s): none 1162 File extension(s): senml 1164 Macintosh file type code(s): none 1166 Person & email address to contact for further information: Cullen 1167 Jennings 1169 Intended usage: COMMON 1171 Restrictions on usage: None 1173 Author: Cullen Jennings 1175 Change controller: IESG 1177 12.3.4. senml-exi Media Type Registration 1179 Type name: application 1181 Subtype name: senml-exi 1183 Required parameters: none 1185 Optional parameters: none 1187 Encoding considerations: TBD 1189 Security considerations: TBD 1191 Interoperability considerations: TBD 1193 Published specification: RFC-AAAA 1195 Applications that use this media type: TBD 1197 Additional information: 1199 Magic number(s): none 1201 File extension(s): senml 1203 Macintosh file type code(s): none 1204 Person & email address to contact for further information: Cullen 1205 Jennings 1207 Intended usage: COMMON 1209 Restrictions on usage: None 1211 Author: Cullen Jennings 1213 Change controller: IESG 1215 12.4. XML Namespace Registration 1217 This document registers the following XML namespaces in the IETF XML 1218 registry defined in [RFC3688]. 1220 URI: urn:ietf:params:xml:ns:senml 1222 Registrant Contact: The IESG. 1224 XML: N/A, the requested URIs are XML namespaces 1226 12.5. CoAP Content-Format Registration 1228 IANA is requested to assign CoAP Content-Format IDs for the SenML 1229 media types in the "CoAP Content-Formats" sub-registry, within the 1230 "CoRE Parameters" registry [RFC7252]. All IDs are assigned from the 1231 "Expert Review" (0-255) range. The assigned IDs are show in Table 4. 1233 +-------------------------+-----+ 1234 | Media type | ID | 1235 +-------------------------+-----+ 1236 | application/senml+json | TBD | 1237 | application/sensml+json | TBD | 1238 | application/senml+cbor | TBD | 1239 | application/senml+xml | TBD | 1240 | application/sensml+xml | TBD | 1241 | application/senml-exi | TBD | 1242 +-------------------------+-----+ 1244 Table 4: CoAP Content-Format IDs 1246 13. Security Considerations 1248 See Section 14. Further discussion of security properties can be 1249 found in Section 12.3. 1251 14. Privacy Considerations 1253 Sensor data can range from information with almost no security 1254 considerations, such as the current temperature in a given city, to 1255 highly sensitive medical or location data. This specification 1256 provides no security protection for the data but is meant to be used 1257 inside another container or transport protocol such as S/MIME or HTTP 1258 with TLS that can provide integrity, confidentiality, and 1259 authentication information about the source of the data. 1261 15. Acknowledgement 1263 We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 1264 Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, Carsten 1265 Bormann, and Christian Amsuess for their review comments. 1267 The CBOR Representation text and CDDL was contributed by Carsten 1268 Bormann. 1270 16. References 1272 16.1. Normative References 1274 [BIPM] Bureau International des Poids et Mesures, "The 1275 International System of Units (SI)", 8th edition, 2006. 1277 [IEEE.754.1985] 1278 Institute of Electrical and Electronics Engineers, 1279 "Standard for Binary Floating-Point Arithmetic", IEEE 1280 Standard 754, August 1985. 1282 [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the 1283 International System of Units (SI)", NIST Special 1284 Publication 811, 2008. 1286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1287 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1288 RFC2119, March 1997, 1289 . 1291 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1292 DOI 10.17487/RFC3688, January 2004, 1293 . 1295 [RFC4627] Crockford, D., "The application/json Media Type for 1296 JavaScript Object Notation (JSON)", RFC 4627, DOI 1297 10.17487/RFC4627, July 2006, 1298 . 1300 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1301 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1302 . 1304 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1305 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1306 DOI 10.17487/RFC5226, May 2008, 1307 . 1309 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1310 Specifications and Registration Procedures", BCP 13, RFC 1311 6838, DOI 10.17487/RFC6838, January 2013, 1312 . 1314 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1315 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1316 October 2013, . 1318 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1319 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1320 2014, . 1322 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1323 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 1324 RFC7252, June 2014, 1325 . 1327 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1328 DOI 10.17487/RFC7303, July 2014, 1329 . 1331 [W3C.REC-exi-20110310] 1332 Schneider, J. and T. Kamiya, "Efficient XML Interchange 1333 (EXI) Format 1.0", World Wide Web Consortium 1334 Recommendation REC-exi-20110310, March 2011, 1335 . 1337 16.2. Informative References 1339 [I-D.arkko-core-dev-urn] 1340 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource 1341 Names for Device Identifiers", draft-arkko-core-dev-urn-03 1342 (work in progress), July 2012. 1344 [I-D.greevenbosch-appsawg-cbor-cddl] 1345 Vigano, C. and H. Birkholz, "CBOR data definition language 1346 (CDDL): a notational convention to express CBOR data 1347 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 1348 in progress), March 2016. 1350 [I-D.ietf-core-links-json] 1351 Li, K., Rahman, A., and C. Bormann, "Representing CoRE 1352 Formats in JSON and CBOR", draft-ietf-core-links-json-04 1353 (work in progress), November 2015. 1355 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1356 May 1997, . 1358 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1359 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1360 3986, DOI 10.17487/RFC3986, January 2005, 1361 . 1363 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1364 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 1365 10.17487/RFC4122, July 2005, 1366 . 1368 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1369 Address Text Representation", RFC 5952, DOI 10.17487/ 1370 RFC5952, August 2010, 1371 . 1373 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1374 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1375 . 1377 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1378 Considerations for IPv6 Address Generation Mechanisms", 1379 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1380 . 1382 [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units 1383 of Measure (UCUM)", Regenstrief Institute and Indiana 1384 University School of Informatics, 2013, 1385 . 1387 Appendix A. Links extension 1389 An extension to SenML to support links is expected to be registered 1390 and defined by [I-D.ietf-core-links-json]. 1392 The link extension can be an array of objects that can be used for 1393 additional information. Each object in the Link array is constrained 1394 to being a map of strings to strings with unique keys. 1396 The following shows an example of the links extension. 1398 [{"bn": "urn:dev:ow:10e2073a01080063/", 1399 "bt": 1320078429, 1400 "l": "[{\"href\":\"humidity\",\"foo\":\"bar1\"}\" 1401 }, 1402 { "n": "temperature", "v": 27.2, "u": "Cel" }, 1403 { "n": "humidity", "v": 80, "u": "%RH" } 1404 ] 1406 Authors' Addresses 1408 Cullen Jennings 1409 Cisco 1410 400 3rd Avenue SW 1411 Calgary, AB T2P 4H2 1412 Canada 1414 Phone: +1 408 421-9990 1415 Email: fluffy@cisco.com 1417 Zach Shelby 1418 ARM 1419 150 Rose Orchard 1420 San Jose 95134 1421 USA 1423 Phone: +1-408-203-9434 1424 Email: zach.shelby@arm.com 1426 Jari Arkko 1427 Ericsson 1428 Jorvas 02420 1429 Finland 1431 Email: jari.arkko@piuha.net 1432 Ari Keranen 1433 Ericsson 1434 Jorvas 02420 1435 Finland 1437 Email: ari.keranen@ericsson.com