idnits 2.17.1 draft-ietf-core-senml-02.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 8, 2016) is 2842 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 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-05 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 3 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: January 9, 2017 ARM 6 J. Arkko 7 A. Keranen 8 Ericsson 9 C. Bormann 10 Universitaet Bremen TZI 11 July 8, 2016 13 Media Types for Sensor Markup Language (SenML) 14 draft-ietf-core-senml-02 16 Abstract 18 This specification defines media types for representing simple sensor 19 measurements and device parameters in the Sensor Markup Language 20 (SenML). Representations are defined in JavaScript Object Notation 21 (JSON), Concise Binary Object Representation (CBOR), eXtensible 22 Markup Language (XML), and Efficient XML Interchange (EXI), which 23 share the common SenML data model. A simple sensor, such as a 24 temperature sensor, could use this media type in protocols such as 25 HTTP or CoAP to transport the measurements of the sensor or to be 26 configured. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 5 66 4.1. Base attributes . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Regular attributes . . . . . . . . . . . . . . . . . . . 6 68 4.3. Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. Associating Meta-data . . . . . . . . . . . . . . . . . . 8 70 5. JSON Representation (application/senml+json) . . . . . . . . 8 71 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 9 73 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 9 74 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 11 75 5.1.4. Collection of Resources . . . . . . . . . . . . . . . 12 76 6. CBOR Representation (application/senml+cbor) . . . . . . . . 12 77 7. XML Representation (application/senml+xml) . . . . . . . . . 13 78 8. EXI Representation (application/senml-exi) . . . . . . . . . 15 79 9. Usage Considerations . . . . . . . . . . . . . . . . . . . . 17 80 10. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 11.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 20 83 11.2. SenML label registry . . . . . . . . . . . . . . . . . . 24 84 11.3. Media Type Registration . . . . . . . . . . . . . . . . 24 85 11.3.1. senml+json Media Type Registration . . . . . . . . . 24 86 11.3.2. senml+cbor Media Type Registration . . . . . . . . . 25 87 11.3.3. senml+xml Media Type Registration . . . . . . . . . 26 88 11.3.4. senml-exi Media Type Registration . . . . . . . . . 27 89 11.4. XML Namespace Registration . . . . . . . . . . . . . . . 28 90 11.5. CoAP Content-Format Registration . . . . . . . . . . . . 28 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 92 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 93 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 96 15.2. Informative References . . . . . . . . . . . . . . . . . 30 97 Appendix A. Links extension . . . . . . . . . . . . . . . . . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 100 1. Overview 102 Connecting sensors to the Internet is not new, and there have been 103 many protocols designed to facilitate it. This specification defines 104 new media types for carrying simple sensor information in a protocol 105 such as HTTP or CoAP. This format was designed so that processors 106 with very limited capabilities could easily encode a sensor 107 measurement into the media type, while at the same time a server 108 parsing the data could relatively efficiently collect a large number 109 of sensor measurements. The markup language can be used for a 110 variety of data flow models, most notably data feeds pushed from a 111 sensor to a collector, and the web resource model where the sensor is 112 requested as a resource representation (e.g., "GET /sensor/ 113 temperature"). 115 There are many types of more complex measurements and measurements 116 that this media type would not be suitable for. SenML strikes a 117 balance between having some information about the sensor carried with 118 the sensor data so that the data is self describing but it also tries 119 to make that a fairly minimal set of auxiliary information for 120 efficiency reason. Other information about the sensor can be 121 discovered by other methods such as using the CoRE Link Format 122 [RFC6690]. 124 SenML is defined by a data model for measurements and simple meta- 125 data about measurements and devices. The data is structured as a 126 single array that contains a series of SenML Records which can each 127 contain attributes such as an unique identifier for the sensor, the 128 time the measurement was made, the unit the measurement is in, and 129 the current value of the sensor. Serializations for this data model 130 are defined for JSON [RFC7159], CBOR [RFC7049], XML, and Efficient 131 XML Interchange (EXI) [W3C.REC-exi-20110310]. 133 For example, the following shows a measurement from a temperature 134 gauge encoded in the JSON syntax. 136 [{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }] 138 In the example above, the array has a single SenML Record with a 139 measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a 140 current value of 23.1 degrees Celsius. 142 2. Requirements and Design Goals 144 The design goal is to be able to send simple sensor measurements in 145 small packets on mesh networks from large numbers of constrained 146 devices. Keeping the total size of payload under 80 bytes makes this 147 easy to use on a wireless mesh network. It is always difficult to 148 define what small code is, but there is a desire to be able to 149 implement this in roughly 1 KB of flash on a 8 bit microprocessor. 150 Experience with Google power meter and large scale deployments has 151 indicated that the solution needs to support allowing multiple 152 measurements to be batched into a single HTTP or CoAP request. This 153 "batch" upload capability allows the server side to efficiently 154 support a large number of devices. It also conveniently supports 155 batch transfers from proxies and storage devices, even in situations 156 where the sensor itself sends just a single data item at a time. The 157 multiple measurements could be from multiple related sensors or from 158 the same sensor but at different times. 160 The basic design is an array with a series of measurements. The 161 following example shows two measurements made at different times. 162 The value of a measurement is in the "v" tag, the time of a 163 measurement is in the "t" tag, the "n" tag has a unique sensor name, 164 and the unit of the measurement is carried in the "u" tag. 166 [ 167 { "n": "urn:dev:ow:10e2073a01080063", 168 "t": 1276020076, "v":23.5, "u":"Cel" }, 169 { "n": "urn:dev:ow:10e2073a01080063", 170 "t": 1276020091, "v":23.6, "u":"Cel" } 171 ] 173 To keep the messages small, it does not make sense to repeat the "n" 174 tag in each SenML Record so there is a concept of a Base Name which 175 is simply a string that is prepended to the Name field of all 176 elements in that record and any records that follow it. So a more 177 compact form of the example above is the following. 179 [ 180 { "bn": "urn:dev:ow:10e2073a01080063", 181 "t": 1276020076, "v":23.5, "u":"Cel" }, 182 { "t": 1276020091, "v":23.6, "u":"Cel" } 183 ] 185 In the above example the Base Name is in the "bn" tag and the "n" 186 tags in each Record are the empty string so they are omitted. 188 Some devices have accurate time while others do not so SenML supports 189 absolute and relative times. Time is represented in floating point 190 as seconds and values greater than zero represent an absolute time 191 relative to the Unix epoch while values of 0 or less represent a 192 relative time in the past from the current time. A simple sensor 193 with no absolute wall clock time might take a measurement every 194 second and batch up 60 of them then send it to a server. It would 195 include the relative time the measurement was made to the time the 196 batch was send in the SenML Pack. The server might have accurate NTP 197 time and use the time it received the data, and the relative offset, 198 to replace the times in the SenML with absolute times before saving 199 the SenML Pack in a document database. 201 3. Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in 206 [RFC2119]. 208 This document also uses the following terms: 210 SenML Record: One measurement or configuration instance in time 211 presented using the SenML data model. 213 SenML Pack: One or more SenML Records in an array structure. 215 4. SenML Structure and Semantics 217 Each SenML Pack carries a single array that represents a set of 218 measurements and/or parameters. This array contains a series of 219 SenML Records with several attributes described below. There are two 220 kind of attributes: base and regular. The base attributes can only 221 be included in the first SenML Record and they apply to the entries 222 in all Records. All base attributes are optional. Regular 223 attributes can be included in any SenML Record and apply only to that 224 Record. 226 4.1. Base attributes 228 Base Name: This is a string that is prepended to the names found in 229 the entries. 231 Base Time: A base time that is added to the time found in an entry. 233 Base Unit: A base unit that is assumed for all entries, unless 234 otherwise indicated. If a record does not contain a Unit value, 235 then the Base Unit is used. Otherwise the value found in the Unit 236 (if any) is used. 238 Base Value: A base value is added to the value found in an entry, 239 similar to Base Time. 241 Version: Version number of media type format. This attribute is an 242 optional positive integer and defaults to 5 if not present. [RFC 243 Editor: change the default value to 10 when this specification is 244 published as an RFC and remove this note] 246 4.2. Regular attributes 248 Name: Name of the sensor or parameter. When appended to the Base 249 Name attribute, this must result in a globally unique identifier 250 for the resource. The name is optional, if the Base Name is 251 present. If the name is missing, Base Name must uniquely identify 252 the resource. This can be used to represent a large array of 253 measurements from the same sensor without having to repeat its 254 identifier on every measurement. 256 Unit: Units for a measurement value. Optional. If the Record has 257 no Unit, the Base Unit is used as the Unit. Having no Unit and no 258 Base Unit is allowed. 260 Value Value of the entry. Optional if a Sum value is present, 261 otherwise required. Values are represented using three basic data 262 types, Floating point numbers ("v" field for "Value"), Booleans 263 ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and 264 Binary Data ("vd" for "Data Value") . Exactly one of these four 265 fields MUST appear unless there is Sum field in which case it is 266 allowed to have no Value field or to have "v" field. 268 Sum: Integrated sum of the values over time. Optional. This 269 attribute is in the units specified in the Unit value multiplied 270 by seconds. 272 Time: Time when value was recorded. Optional. 274 Update Time: An optional time in seconds that represents the maximum 275 time before this sensor will provide an updated reading for a 276 measurement. This can be used to detect the failure of sensors or 277 communications path from the sensor. 279 4.3. Considerations 281 The SenML format can be extended with further custom attributes. 282 Both new base and regular attributes are allowed. See Section 11.2 283 for details. Implementations MUST ignore attributes they don't 284 recognize. 286 Systems reading one of the objects MUST check for the Version 287 attribute. If this value is a version number larger than the version 288 which the system understands, the system SHOULD NOT use this object. 289 This allows the version number to indicate that the object contains 290 mandatory to understand attributes. New version numbers can only be 291 defined in an RFC that updates this specification or it successors. 293 The Name value is concatenated to the Base Name value to get the name 294 of the sensor. The resulting name needs to uniquely identify and 295 differentiate the sensor from all others. If the object is a 296 representation resulting from the request of a URI [RFC3986], then in 297 the absence of the Base Name attribute, this URI is used as the 298 default value of Base Name. Thus in this case the Name field needs 299 to be unique for that URI, for example an index or subresource name 300 of sensors handled by the URI. 302 Alternatively, for objects not related to a URI, a unique name is 303 required. In any case, it is RECOMMENDED that the full names are 304 represented as URIs or URNs [RFC2141]. One way to create a unique 305 name is to include some bit string that has guaranteed uniqueness 306 (such as a 1-wire address) that is assigned to the device. Some of 307 the examples in this draft use the device URN type as specified in 308 [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to 309 generate a unique name. Note that long-term stable unique 310 identifiers are problematic for privacy reasons [RFC7721] and should 311 be used with care or avoided. 313 The resulting concatenated name MUST consist only of characters out 314 of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 315 and it MUST start with a character out of the set "A" to "Z", "a" to 316 "z", or "0" to "9". This restricted character set was chosen so that 317 these names can be directly used as in other types of URI including 318 segments of an HTTP path with no special encoding and can be directly 319 used in many databases and analytic systems. [RFC5952] contains 320 advice on encoding an IPv6 address in a name. 322 If either the Base Time or Time value is missing, the missing 323 attribute is considered to have a value of zero. The Base Time and 324 Time values are added together to get the time of measurement. A 325 time of zero indicates that the sensor does not know the absolute 326 time and the measurement was made roughly "now". A negative value is 327 used to indicate seconds in the past from roughly "now". A positive 328 value is used to indicate the number of seconds, excluding leap 329 seconds, since the start of the year 1970 in UTC. 331 Representing the statistical characteristics of measurements, such as 332 accuracy, can be very complex. Future specification may add new 333 attributes to provide better information about the statistical 334 properties of the measurement. 336 A SenML object is referred to as "expanded" if it does not contain 337 any base values and has no relative times. 339 4.4. Associating Meta-data 341 SenML is designed to carry the minimum dynamic information about 342 measurements, and for efficiency reasons does not carry significant 343 static meta-data about the device, object or sensors. Instead, it is 344 assumed that this meta-data is carried out of band. For web 345 resources using SenML Packs, this meta-data can be made available 346 using the CoRE Link Format [RFC6690]. The most obvious use of this 347 link format is to describe that a resource is available in a SenML 348 format in the first place. The relevant media type indicator is 349 included in the Content-Type (ct=) attribute. 351 5. JSON Representation (application/senml+json) 353 The SenML labels (JSON object member names) shown in Table 1 are used 354 in JSON SenML Record attributes. 356 +---------------+-------+---------+ 357 | Name | label | Type | 358 +---------------+-------+---------+ 359 | Base Name | bn | String | 360 | Base Time | bt | Number | 361 | Base Unit | bu | String | 362 | Base Value | bv | Number | 363 | Version | bver | Number | 364 | Name | n | String | 365 | Unit | u | String | 366 | Value | v | Number | 367 | String Value | vs | String | 368 | Boolean Value | vb | Boolean | 369 | Data Value | vd | String | 370 | Value Sum | s | Number | 371 | Time | t | Number | 372 | Update Time | ut | Number | 373 +---------------+-------+---------+ 375 Table 1: JSON SenML Labels 377 The root content consists of an array with one JSON object for each 378 SenML Record. All the fields in the above table MAY occur in the 379 records with the type specified in the table. 381 Only the UTF-8 form of JSON is allowed. Characters in the String 382 Value are encoded using the escape sequences defined in [RFC7159]. 383 Characters in the Data Value are base64 encoded with URL safe 384 alphabet as defined in Section 5 of [RFC4648]. 386 Systems receiving measurements MUST be able to process the range of 387 floating point numbers that are representable as an IEEE double- 388 precision floating-point numbers [IEEE.754.1985]. The number of 389 significant digits in any measurement is not relevant, so a reading 390 of 1.1 has exactly the same semantic meaning as 1.10. If the value 391 has an exponent, the "e" MUST be in lower case. The mantissa SHOULD 392 be less than 19 characters long and the exponent SHOULD be less than 393 5 characters long. This allows time values to have better than micro 394 second precision over the next 100 years. 396 5.1. Examples 398 TODO - Add example with string, data, boolean, and base value 400 5.1.1. Single Datapoint 402 The following shows a temperature reading taken approximately "now" 403 by a 1-wire sensor device that was assigned the unique 1-wire address 404 of 10e2073a01080063: 406 [{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }] 408 5.1.2. Multiple Datapoints 410 The following example shows voltage and current now, i.e., at an 411 unspecified time. 413 [ {"bn": "urn:dev:ow:10e2073a01080063", 414 "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, 415 {"n": "current", "t": 0, "u": "A", "v": 1.2 } 416 ] 418 The next example is similar to the above one, but shows current at 419 Tue Jun 8 18:01:16.001 UTC 2010 and at each second for the previous 5 420 seconds. 422 [{"bn": "urn:dev:ow:10e2073a01080063/", 423 "bt": 1276020076.001, 424 "bu": "A", 425 "bver": 5, 426 "n": "voltage", "u": "V", "v": 120.1 }, 427 { "n": "current", "t": -5, "v": 1.2 }, 428 { "n": "current", "t": -4, "v": 1.30 }, 429 { "n": "current", "t": -3, "v": 0.14e1 }, 430 { "n": "current", "t": -2, "v": 1.5 }, 431 { "n": "current", "t": -1, "v": 1.6 }, 432 { "n": "current", "t": 0, "v": 1.7 } 433 ] 435 Note that in some usage scenarios of SenML the implementations MAY 436 store or transmit SenML in a stream-like fashion, where data is 437 collected over time and continuously added to the object. This mode 438 of operation is optional, but systems or protocols using SenML in 439 this fashion MUST specify that they are doing this. SenML defines a 440 separate media type to indicate Sensor Streaming Markup Language 441 (SensML) for this usage (see Section 11.3.1). In this situation the 442 SensML stream can be sent and received in a partial fashion, i.e., a 443 measurement entry can be read as soon as the SenML Record is received 444 and not have to wait for the full SensML Stream to be complete. 446 For instance, the following stream of measurements may be sent via a 447 long lived HTTP POST from the producer of a SensML to the consumer of 448 that, and each measurement object may be reported at the time it was 449 measured: 451 [ {"bn": "urn:dev:ow:10e2073a01080063", 452 "bt": 1320067464, 453 "bu": "%RH", 454 "v": 21.2, "t": 0 }, 455 { "v": 21.3, "t": 10 }, 456 { "v": 21.4, "t": 20 }, 457 { "v": 21.4, "t": 30 }, 458 { "v": 21.5, "t": 40 }, 459 { "v": 21.5, "t": 50 }, 460 { "v": 21.5, "t": 60 }, 461 { "v": 21.6, "t": 70 }, 462 { "v": 21.7, "t": 80 }, 463 { "v": 21.5, "t": 90 }, 464 ... 466 5.1.3. Multiple Measurements 468 The following example shows humidity measurements from a mobile 469 device with a 1-wire address 10e2073a01080063, starting at Mon Oct 31 470 13:24:24 UTC 2011. The device also provides position data, which is 471 provided in the same measurement or parameter array as separate 472 entries. Note time is used to for correlating data that belongs 473 together, e.g., a measurement and a parameter associated with it. 474 Finally, the device also reports extra data about its battery status 475 at a separate time. 477 [{"bn": "urn:dev:ow:10e2073a01080063", 478 "bt": 1320067464, 479 "bu": "%RH", 480 "v": 20.0, "t": 0 }, 481 { "v": 24.30621, "u": "lon", "t": 0 }, 482 { "v": 60.07965, "u": "lat", "t": 0 }, 483 { "v": 20.3, "t": 60 }, 484 { "v": 24.30622, "u": "lon", "t": 60 }, 485 { "v": 60.07965, "u": "lat", "t": 60 }, 486 { "v": 20.7, "t": 120 }, 487 { "v": 24.30623, "u": "lon", "t": 120 }, 488 { "v": 60.07966, "u": "lat", "t": 120 }, 489 { "v": 98.0, "u": "%EL", "t": 150 }, 490 { "v": 21.2, "t": 180 }, 491 { "v": 24.30628, "u": "lon", "t": 180 }, 492 { "v": 60.07967, "u": "lat", "t": 180 } 493 ] 495 The size of this example represented in various forms, as well as 496 that form compressed with gzip is given in the following table. 498 +----------+------+-----------------+ 499 | Encoding | Size | Compressed Size | 500 +----------+------+-----------------+ 501 | JSON | 573 | 206 | 502 | XML | 649 | 235 | 503 | CBOR | 254 | 196 | 504 | EXI | 173 | 196 | 505 +----------+------+-----------------+ 507 Table 2: Size Comparisons 509 Note the EXI sizes are not using the schema guidance so the EXI 510 representation could be a bit smaller. 512 5.1.4. Collection of Resources 514 The following example shows how to query one device that can provide 515 multiple measurements. The example assumes that a client has fetched 516 information from a device at 2001:db8::2 by performing a GET 517 operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, 518 and has gotten two separate values as a result, a temperature and 519 humidity measurement. 521 [{"bn": "http://[2001:db8::2]/", 522 "bt": 1320078429, 523 "bver": 5, 524 "n": "temperature", "v": 27.2, "u": "Cel" }, 525 { "n": "humidity", "v": 80, "u": "%RH" } 526 ] 528 6. CBOR Representation (application/senml+cbor) 530 The CBOR [RFC7049] representation is equivalent to the JSON 531 representation, with the following changes: 533 o For compactness, the CBOR representation uses integers for the map 534 keys defined in Table 3. This table is conclusive, i.e., there is 535 no intention to define any additional integer map keys; any 536 extensions will use string map keys. 538 o For JSON Numbers, the CBOR representation can use integers, 539 floating point numbers, or decimal fractions (CBOR Tag 4); the 540 common limitations of JSON implementations are not relevant for 541 these. For the version number, however, only an unsigned integer 542 is allowed. 544 +---------------+------------+------------+ 545 | Name | JSON label | CBOR label | 546 +---------------+------------+------------+ 547 | Version | bver | -1 | 548 | Base Name | bn | -2 | 549 | Base Time | bt | -3 | 550 | Base Units | bu | -4 | 551 | Base Value | bv | -5 | 552 | Name | n | 0 | 553 | Units | u | 1 | 554 | Value | v | 2 | 555 | String Value | vs | 3 | 556 | Boolean Value | vb | 4 | 557 | Value Sum | s | 5 | 558 | Time | t | 6 | 559 | Update Time | ut | 7 | 560 | Data Value | vd | 8 | 561 +---------------+------------+------------+ 563 Table 3: CBOR representation: integers for map keys 565 The following example shows a dump of the CBOR example for the same 566 sensor measurement as in Section 5.1.2. 568 0000 87 a7 21 78 1c 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:| 569 0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 33 |10e2073a01080063| 570 0020 2f 22 fb 41 d3 03 a1 5b 00 10 62 23 61 41 20 05 |/".A...[..b#aA .| 571 0030 00 67 76 6f 6c 74 61 67 65 01 61 56 02 fb 40 5e |.gvoltage.aV..@^| 572 0040 06 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 |.fffff..gcurrent| 573 0050 06 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 |.$..?.333333..gc| 574 0060 75 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc |urrent.#..?.....| 575 0070 cc cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb |....gcurrent."..| 576 0080 3f f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 |?.ffffff..gcurre| 577 0090 6e 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 |nt.!..>...gcurre| 578 00a0 6e 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 |nt. ..?.........| 579 00b0 67 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 |gcurrent....?.33| 580 00c0 33 33 33 33 |3333| 581 00c4 583 7. XML Representation (application/senml+xml) 585 A SenML Pack or Stream can also be represented in XML format as 586 defined in this section. The following example shows an XML example 587 for the same sensor measurement as in Section 5.1.2. 589 590 592 593 594 595 596 597 598 600 The SenML Stream is represented as a sensml tag that contains a 601 series of senml tags for each SenML Record. The SenML Fields are 602 represents as XML attributes. The following table shows the mapping 603 of the SenML labels to the attribute names and types used in the XML 604 senml tags. 606 +---------------+------+---------+ 607 | Name | XML | Type | 608 +---------------+------+---------+ 609 | Base Name | bn | string | 610 | Base Time | bt | double | 611 | Base Unit | bu | string | 612 | Base Value | bv | double | 613 | Base Version | bver | int | 614 | Name | n | string | 615 | Unit | u | string | 616 | Value | v | double | 617 | String Value | vs | string | 618 | Data Value | vd | string | 619 | Boolean Value | vb | boolean | 620 | Value Sum | s | double | 621 | Time | t | double | 622 | Update Time | ut | double | 623 +---------------+------+---------+ 625 Table 4: XML SenML Labels 627 The RelaxNG schema for the XML is: 629 default namespace = "urn:ietf:params:xml:ns:senml" 630 namespace rng = "http://relaxng.org/ns/structure/1.0" 632 senml = element senml { 633 attribute bn { xsd:string }?, 634 attribute bt { xsd:double }?, 635 attribute bv { xsd:double }?, 636 attribute bu { xsd:string }?, 637 attribute bver { xsd:int }?, 639 attribute n { xsd:string }?, 640 attribute s { xsd:double }?, 641 attribute t { xsd:double }?, 642 attribute u { xsd:string }?, 643 attribute ut { xsd:double }?, 645 attribute v { xsd:double }?, 646 attribute vb { xsd:boolean }?, 647 attribute vs { xsd:string }?, 648 attribute vd { xsd:string }? 649 } 651 sensml = 652 element sensml { 653 senml+ 654 } 656 start = sensml 658 8. EXI Representation (application/senml-exi) 660 For efficient transmission of SenML over e.g. a constrained network, 661 Efficient XML Interchange (EXI) can be used. This encodes the XML 662 Schema structure of SenML into binary tags and values rather than 663 ASCII text. An EXI representation of SenML SHOULD be made using the 664 strict schema-mode of EXI. This mode however does not allow tag 665 extensions to the schema, and therefore any extensions will be lost 666 in the encoding. For uses where extensions need to be preserved in 667 EXI, the non-strict schema mode of EXI MAY be used. 669 The EXI header option MUST be included. An EXI schemaID options MUST 670 be set to the value of "a" indicating the scheme provided in this 671 specification. Future revisions to the schema can change this 672 schemaID to allow for backwards compatibility. When the data will be 673 transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it 674 simply makes things larger and is redundant to information provided 675 in the Content-Type header. 677 TODO - examples probably have the wrong setting for the schemaID 679 The following is the XSD Schema to be used for strict schema guided 680 EXI processing. It is generated from the RelaxNG. 682 683 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 714 The following shows a hexdump of the EXI produced from encoding the 715 following XML example. Note this example is the same information as 716 the first example in Section 5.1.2 in JSON format. 718 719 721 722 724 Which compresses with EXI to the following displayed in hexdump: 726 0000 a0 30 3d cd 95 b9 b5 b0 b9 9d 95 b8 b9 e1 cd 90 |.0=.............| 727 0010 80 eb ab 93 71 d3 23 2b b1 d3 7b b9 d1 89 83 29 |....q.#+..{....)| 728 0020 91 81 b9 9b 09 81 89 81 c1 81 81 b1 9a 84 bb 37 |...............7| 729 0030 b6 3a 30 b3 b2 90 1a b1 58 84 c0 33 04 b1 ba b9 |.:0.....X..3....| 730 0040 39 32 b7 3a 10 1a 09 06 40 38 |92.:....@8| 731 004a 733 The above example used the bit packed form of EXI but it is also 734 possible to use a byte packed form of EXI which can makes it easier 735 for a simple sensor to produce valid EXI without really implementing 736 EXI. Consider the example of a temperature sensor that produces a 737 value in tenths of degrees Celsius over a range of 0.0 to 55.0. It 738 would produce an XML SenML file such as: 740 741 742 744 The compressed form, using the byte alignment option of EXI, for the 745 above XML is the following: 747 0000 a0 00 48 81 ee 6c ad cd ad 85 cc ec ad c5 cf 0e |..H..l..........| 748 0010 6c 80 01 06 1d 75 72 6e 3a 64 65 76 3a 6f 77 3a |l....urn:dev:ow:| 749 0020 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 33 |10e2073a01080063| 750 0030 02 05 43 65 6c 01 00 e7 01 01 00 03 01 |..Cel........| 751 003d 753 A small temperature sensor devices that only generates this one EXI 754 file does not really need an full EXI implementation. It can simply 755 hard code the output replacing the 1-wire device ID starting at byte 756 0x20 and going to byte 0x2F with it's device ID, and replacing the 757 value "0xe7 0x01" at location 0x37 and 0x38 with the current 758 temperature. The EXI Specification [W3C.REC-exi-20110310] contains 759 the full information 'on how floating point numbers are represented, 760 but for the purpose of this sensor, the temperature can be converted 761 to an integer in tenths of degrees (231 in this example). EXI stores 762 7 bits of the integer in each byte with the top bit set to one if 763 there are further bytes. So the first bytes at is set to low 7 bits 764 of the integer temperature in tenths of degrees plus 0x80. In this 765 example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the 766 integer temperature in tenths of degrees right shifted 7 bits. In 767 this example 231 >> 7 = 0x01. 769 9. Usage Considerations 771 The measurements support sending both the current value of a sensor 772 as well as the an integrated sum. For many types of measurements, 773 the sum is more useful than the current value. For example, an 774 electrical meter that measures the energy a given computer uses will 775 typically want to measure the cumulative amount of energy used. This 776 is less prone to error than reporting the power each second and 777 trying to have something on the server side sum together all the 778 power measurements. If the network between the sensor and the meter 779 goes down over some period of time, when it comes back up, the 780 cumulative sum helps reflect what happened while the network was 781 down. A meter like this would typically report a measurement with 782 the units set to watts, but it would put the sum of energy used in 783 the "s" attribute of the measurement. It might optionally include 784 the current power in the "v" attribute. 786 While the benefit of using the integrated sum is fairly clear for 787 measurements like power and energy, it is less obvious for something 788 like temperature. Reporting the sum of the temperature makes it easy 789 to compute averages even when the individual temperature values are 790 not reported frequently enough to compute accurate averages. 791 Implementors are encouraged to report the cumulative sum as well as 792 the raw value of a given sensor. 794 Applications that use the cumulative sum values need to understand 795 they are very loosely defined by this specification, and depending on 796 the particular sensor implementation may behave in unexpected ways. 797 Applications should be able to deal with the following issues: 799 1. Many sensors will allow the cumulative sums to "wrap" back to 800 zero after the value gets sufficiently large. 802 2. Some sensors will reset the cumulative sum back to zero when the 803 device is reset, loses power, or is replaced with a different 804 sensor. 806 3. Applications cannot make assumptions about when the device 807 started accumulating values into the sum. 809 Typically applications can make some assumptions about specific 810 sensors that will allow them to deal with these problems. A common 811 assumption is that for sensors whose measurement values are always 812 positive, the sum should never get smaller; so if the sum does get 813 smaller, the application will know that one of the situations listed 814 above has happened. 816 10. CDDL 818 For reference, the JSON and CBOR representations can be described 819 with the common CDDL [I-D.greevenbosch-appsawg-cbor-cddl] 820 specification in Figure 1. 822 SenML-Pack = [initial-record, * follow-on-record] 824 initial-record = initial-defined .and initial-generic 825 follow-on-record = follow-on-defined .and follow-on-generic 827 ; first do a specification of the labels as defined: 829 initial-defined = { 830 ? bn => tstr, ; Base Name 831 ? bt => numeric, ; Base Time 832 ? bu => tstr, ; Base Units 833 ? bv => numeric, ; Base value 834 ? bver => uint, ; Base Version 835 follow-on-defined-group, 836 + base-key-value-pair 837 } 839 follow-on-defined-group = ( 840 ? n => tstr, ; Name 841 ? u => tstr, ; Units 842 ? s => numeric, ; Value Sum 843 ? t => numeric, ; Time 844 ? ut => numeric, ; Update Time 845 * key-value-pair, 846 ? ( v => numeric // ; Numeric Value 847 vs => tstr // ; String Value 848 vb => bool // ; Boolean Value 849 vd => binary-value ) ; Data Value 850 ) 851 follow-on-defined = { follow-on-defined-group } 853 ; now define the generic versions 855 initial-generic = { 856 follow-on-generic-group, 857 * base-key-value-pair, 858 } 860 follow-on-generic-group = ( 861 + key-value-pair, 862 ) 863 follow-on-generic = { follow-on-generic-group } 865 key-value-pair = ( non-b-label => value ) 867 base-key-value-pair = ( b-label => value ) 869 non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint 870 b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint 872 value = tstr / binary-value / numeric / bool 873 numeric = number / decfrac 875 Figure 1: Common CDDL specification for CBOR and JSON SenML 877 For JSON, we use text labels and base64url-encoded binary data 878 (Figure 2). 880 bver = "bver" n = "n" s = "s" 881 bn = "bn" u = "u" t = "t" 882 bt = "bt" v = "v" ut = "ut" 883 bu = "bu" vs = "vs" vd = "vd" 884 bv = "bv" vb = "vb" 886 binary-value = tstr ; base64url encoded 888 Figure 2: JSON-specific CDDL specification for SenML 890 For CBOR, we use integer labels and native binary data (Figure 3). 892 bver = -1 n = 0 s = 5 893 bn = -2 u = 1 t = 6 894 bt = -3 v = 2 ut = 7 895 bu = -4 vs = 3 vd = 8 896 bv = -5 vb = 4 898 binary-value = bstr 900 Figure 3: CBOR-specific CDDL specification for SenML 902 11. IANA Considerations 904 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 905 the RFC number of this specification. 907 11.1. Units Registry 909 IANA will create a registry of SenML unit symbols. The primary 910 purpose of this registry is to make sure that symbols uniquely map to 911 give type of measurement. Definitions for many of these units can be 912 found in location such as [NIST811] and [BIPM]. Units marked with an 913 asterisk are NOT RECOMMENDED to be produced by new implementations, 914 but are in active use and SHOULD be implemented by consumers that can 915 use the related base units. 917 +----------+------------------------------------+-------+-----------+ 918 | Symbol | Description | Type | Reference | 919 +----------+------------------------------------+-------+-----------+ 920 | m | meter | float | RFC-AAAA | 921 | kg | kilogram | float | RFC-AAAA | 922 | g | gram* | float | RFC-AAAA | 923 | s | second | float | RFC-AAAA | 924 | A | ampere | float | RFC-AAAA | 925 | K | kelvin | float | RFC-AAAA | 926 | cd | candela | float | RFC-AAAA | 927 | mol | mole | float | RFC-AAAA | 928 | Hz | hertz | float | RFC-AAAA | 929 | rad | radian | float | RFC-AAAA | 930 | sr | steradian | float | RFC-AAAA | 931 | N | newton | float | RFC-AAAA | 932 | Pa | pascal | float | RFC-AAAA | 933 | J | joule | float | RFC-AAAA | 934 | W | watt | float | RFC-AAAA | 935 | C | coulomb | float | RFC-AAAA | 936 | V | volt | float | RFC-AAAA | 937 | F | farad | float | RFC-AAAA | 938 | Ohm | ohm | float | RFC-AAAA | 939 | S | siemens | float | RFC-AAAA | 940 | Wb | weber | float | RFC-AAAA | 941 | T | tesla | float | RFC-AAAA | 942 | H | henry | float | RFC-AAAA | 943 | Cel | degrees Celsius | float | RFC-AAAA | 944 | lm | lumen | float | RFC-AAAA | 945 | lx | lux | float | RFC-AAAA | 946 | Bq | becquerel | float | RFC-AAAA | 947 | Gy | gray | float | RFC-AAAA | 948 | Sv | sievert | float | RFC-AAAA | 949 | kat | katal | float | RFC-AAAA | 950 | m2 | square meter (area) | float | RFC-AAAA | 951 | m3 | cubic meter (volume) | float | RFC-AAAA | 952 | l | liter (volume)* | float | RFC-AAAA | 953 | m/s | meter per second (velocity) | float | RFC-AAAA | 954 | m/s2 | meter per square second | float | RFC-AAAA | 955 | | (acceleration) | | | 956 | m3/s | cubic meter per second (flow rate) | float | RFC-AAAA | 957 | l/s | liter per second (flow rate)* | float | RFC-AAAA | 958 | W/m2 | watt per square meter (irradiance) | float | RFC-AAAA | 959 | cd/m2 | candela per square meter | float | RFC-AAAA | 960 | | (luminance) | | | 961 | bit | bit (information content) | float | RFC-AAAA | 962 | bit/s | bit per second (data rate) | float | RFC-AAAA | 963 | lat | degrees latitude (note 2) | float | RFC-AAAA | 964 | lon | degrees longitude (note 2) | float | RFC-AAAA | 965 | pH | pH value (acidity; logarithmic | float | RFC-AAAA | 966 | | quantity) | | | 967 | dB | decibel (logarithmic quantity) | float | RFC-AAAA | 968 | Bspl | bel (sound pressure level; | float | RFC-AAAA | 969 | | logarithmic quantity)* | | | 970 | count | 1 (counter value) | float | RFC-AAAA | 971 | / | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | 972 | | note 1) | | | 973 | % | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | 974 | | note 1)* | | | 975 | %RH | Percentage (Relative Humidity) | float | RFC-AAAA | 976 | %EL | Percentage (remaining battery | float | RFC-AAAA | 977 | | energy level) | | | 978 | EL | seconds (remaining battery energy | float | RFC-AAAA | 979 | | level) | | | 980 | 1/s | 1 per second (event rate) | float | RFC-AAAA | 981 | 1/min | 1 per minute (event rate, "rpm")* | float | RFC-AAAA | 982 | beat/min | 1 per minute (Heart rate in beats | float | RFC-AAAA | 983 | | per minute)* | | | 984 | beats | 1 (Cumulative number of heart | float | RFC-AAAA | 985 | | beats)* | | | 986 +----------+------------------------------------+-------+-----------+ 988 Table 5 990 o Note 1: A value of 0.0 indicates the switch is off while 1.0 991 indicates on and 0.5 would be half on. The preferred name of this 992 unit is "/". For historical reasons, the name "%" is also 993 provided for the same unit - but note that while that name 994 strongly suggests a percentage (0..100) -- it is however NOT a 995 percentage, but the absolute ratio! 997 o Note 2: Assumed to be in WGS84 unless another reference frame is 998 known for the sensor. 1000 New entries can be added to the registration by either Expert Review 1001 or IESG Approval as defined in [RFC5226]. Experts should exercise 1002 their own good judgment but need to consider the following 1003 guidelines: 1005 1. There needs to be a real and compelling use for any new unit to 1006 be added. 1008 2. Units should define the semantic information and be chosen 1009 carefully. Implementors need to remember that the same word may 1010 be used in different real-life contexts. For example, degrees 1011 when measuring latitude have no semantic relation to degrees 1012 when measuring temperature; thus two different units are needed. 1014 3. These measurements are produced by computers for consumption by 1015 computers. The principle is that conversion has to be easily be 1016 done when both reading and writing the media type. The value of 1017 a single canonical representation outweighs the convenience of 1018 easy human representations or loss of precision in a conversion. 1020 4. Use of SI prefixes such as "k" before the unit is not 1021 recommended. Instead one can represent the value using 1022 scientific notation such a 1.2e3. The "kg" unit is exception to 1023 this rule since it is an SI base unit; the "g" unit is provided 1024 for legacy compatibility. 1026 5. For a given type of measurement, there will only be one unit 1027 type defined. So for length, meters are defined and other 1028 lengths such as mile, foot, light year are not allowed. For 1029 most cases, the SI unit is preferred. 1031 6. Symbol names that could be easily confused with existing common 1032 units or units combined with prefixes should be avoided. For 1033 example, selecting a unit name of "mph" to indicate something 1034 that had nothing to do with velocity would be a bad choice, as 1035 "mph" is commonly used to mean miles per hour. 1037 7. The following should not be used because the are common SI 1038 prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, 1039 y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 1041 8. The following units should not be used as they are commonly used 1042 to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 1043 Oe, Gb, sb, Lmb, mph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 1044 BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 1046 9. The unit names are case sensitive and the correct case needs to 1047 be used, but symbols that differ only in case should not be 1048 allocated. 1050 10. A number after a unit typically indicates the previous unit 1051 raised to that power, and the / indicates that the units that 1052 follow are the reciprocal. A unit should have only one / in the 1053 name. 1055 11. A good list of common units can be found in the Unified Code for 1056 Units of Measure [UCUM]. 1058 11.2. SenML label registry 1060 IANA will create a new registry for SenML labels. The initial 1061 content of the registry are shown in Table 1 and Table 4. 1063 New entries can be added to the registration by either Expert Review 1064 or IESG Approval as defined in [RFC5226]. Experts should exercise 1065 their own good judgment but need to consider that shorter labels 1066 should have more strict review. 1068 All new SenML labels that have "base" semantics (see Section 4.1) 1069 must start with character 'b'. Regular labels must not start with 1070 that character. 1072 All new entries must define the Label Name, Label, JSON Type, and XML 1073 Type. 1075 11.3. Media Type Registration 1077 The following registrations are done following the procedure 1078 specified in [RFC6838] and [RFC7303]. 1080 11.3.1. senml+json Media Type Registration 1082 Type name: application 1084 Subtype name: senml+json and sensml+json 1086 Required parameters: none 1088 Optional parameters: none 1090 Encoding considerations: Must be encoded as using a subset of the 1091 encoding allowed in [RFC7159]. See RFC-AAAA for details. This 1092 simplifies implementation of very simple system and does not impose 1093 any significant limitations as all this data is meant for machine to 1094 machine communications and is not meant to be human readable. 1096 Security considerations: Sensor data can contain a wide range of 1097 information ranging from information that is very public, such the 1098 outside temperature in a given city, to very private information that 1099 requires integrity and confidentiality protection, such as patient 1100 health information. This format does not provide any security and 1101 instead relies on the transport protocol that carries it to provide 1102 security. Given applications need to look at the overall context of 1103 how this media type will be used to decide if the security is 1104 adequate. 1106 Interoperability considerations: Applications should ignore any JSON 1107 key value pairs that they do not understand. This allows backwards 1108 compatibility extensions to this specification. The "bver" field can 1109 be used to ensure the receiver supports a minimal level of 1110 functionality needed by the creator of the JSON object. 1112 Published specification: RFC-AAAA 1114 Applications that use this media type: The type is used by systems 1115 that report e.g., electrical power usage and environmental 1116 information such as temperature and humidity. It can be used for a 1117 wide range of sensor reporting systems. 1119 Additional information: 1121 Magic number(s): none 1123 File extension(s): senml and sensml 1125 Macintosh file type code(s): none 1127 Person & email address to contact for further information: Cullen 1128 Jennings 1130 Intended usage: COMMON 1132 Restrictions on usage: None 1134 Author: Cullen Jennings 1136 Change controller: IESG 1138 11.3.2. senml+cbor Media Type Registration 1140 Type name: application 1142 Subtype name: senml+cbor and sensml+cbor 1144 Required parameters: none 1146 Optional parameters: none 1148 Encoding considerations: TBD 1150 Security considerations: See Section 11.3.1 1152 Interoperability considerations: TBD 1153 Published specification: RFC-AAAA 1155 Applications that use this media type: See Section 11.3.1 1157 Additional information: 1159 Magic number(s): none 1161 File extension(s): senmlc and sensmlc 1163 Macintosh file type code(s): none 1165 Person & email address to contact for further information: Cullen 1166 Jennings 1168 Intended usage: COMMON 1170 Restrictions on usage: None 1172 Author: Cullen Jennings 1174 Change controller: IESG 1176 11.3.3. senml+xml Media Type Registration 1178 Type name: application 1180 Subtype name: senml+xml and sensml+xml 1182 Required parameters: none 1184 Optional parameters: none 1186 Encoding considerations: TBD 1188 Security considerations: See Section 11.3.1 1190 Interoperability considerations: TBD 1192 Published specification: RFC-AAAA 1194 Applications that use this media type: See Section 11.3.1 1196 Additional information: 1198 Magic number(s): none 1200 File extension(s): senmlx and sensmlx 1201 Macintosh file type code(s): none 1203 Person & email address to contact for further information: Cullen 1204 Jennings 1206 Intended usage: COMMON 1208 Restrictions on usage: None 1210 Author: Cullen Jennings 1212 Change controller: IESG 1214 11.3.4. senml-exi Media Type Registration 1216 Type name: application 1218 Subtype name: senml-exi and sensml-exi 1220 Required parameters: none 1222 Optional parameters: none 1224 Encoding considerations: TBD 1226 Security considerations: TBD 1228 Interoperability considerations: TBD 1230 Published specification: RFC-AAAA 1232 Applications that use this media type: See Section 11.3.1 1234 Additional information: 1236 Magic number(s): none 1238 File extension(s): senmle and sensmle 1240 Macintosh file type code(s): none 1242 Person & email address to contact for further information: Cullen 1243 Jennings 1245 Intended usage: COMMON 1247 Restrictions on usage: None 1248 Author: Cullen Jennings 1250 Change controller: IESG 1252 11.4. XML Namespace Registration 1254 This document registers the following XML namespaces in the IETF XML 1255 registry defined in [RFC3688]. 1257 URI: urn:ietf:params:xml:ns:senml 1259 Registrant Contact: The IESG. 1261 XML: N/A, the requested URIs are XML namespaces 1263 11.5. CoAP Content-Format Registration 1265 IANA is requested to assign CoAP Content-Format IDs for the SenML 1266 media types in the "CoAP Content-Formats" sub-registry, within the 1267 "CoRE Parameters" registry [RFC7252]. All IDs are assigned from the 1268 "Expert Review" (0-255) range. The assigned IDs are show in Table 6. 1270 +-------------------------+-----+ 1271 | Media type | ID | 1272 +-------------------------+-----+ 1273 | application/senml+json | TBD | 1274 | application/sensml+json | TBD | 1275 | application/senml+cbor | TBD | 1276 | application/senml+xml | TBD | 1277 | application/sensml+xml | TBD | 1278 | application/senml-exi | TBD | 1279 +-------------------------+-----+ 1281 Table 6: CoAP Content-Format IDs 1283 12. Security Considerations 1285 See Section 13. Further discussion of security properties can be 1286 found in Section 11.3. 1288 13. Privacy Considerations 1290 Sensor data can range from information with almost no security 1291 considerations, such as the current temperature in a given city, to 1292 highly sensitive medical or location data. This specification 1293 provides no security protection for the data but is meant to be used 1294 inside another container or transport protocol such as S/MIME or HTTP 1295 with TLS that can provide integrity, confidentiality, and 1296 authentication information about the source of the data. 1298 14. Acknowledgement 1300 We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 1301 Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, and 1302 Christian Amsuess for their review comments. 1304 15. References 1306 15.1. Normative References 1308 [BIPM] Bureau International des Poids et Mesures, "The 1309 International System of Units (SI)", 8th edition, 2006. 1311 [IEEE.754.1985] 1312 Institute of Electrical and Electronics Engineers, 1313 "Standard for Binary Floating-Point Arithmetic", IEEE 1314 Standard 754, August 1985. 1316 [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the 1317 International System of Units (SI)", NIST Special 1318 Publication 811, 2008. 1320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1321 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1322 RFC2119, March 1997, 1323 . 1325 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1326 DOI 10.17487/RFC3688, January 2004, 1327 . 1329 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1330 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1331 . 1333 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1334 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1335 DOI 10.17487/RFC5226, May 2008, 1336 . 1338 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1339 Specifications and Registration Procedures", BCP 13, RFC 1340 6838, DOI 10.17487/RFC6838, January 2013, 1341 . 1343 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1344 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1345 October 2013, . 1347 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1348 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1349 2014, . 1351 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1352 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 1353 RFC7252, June 2014, 1354 . 1356 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1357 DOI 10.17487/RFC7303, July 2014, 1358 . 1360 [W3C.REC-exi-20110310] 1361 Schneider, J. and T. Kamiya, "Efficient XML Interchange 1362 (EXI) Format 1.0", World Wide Web Consortium 1363 Recommendation REC-exi-20110310, March 2011, 1364 . 1366 15.2. Informative References 1368 [I-D.arkko-core-dev-urn] 1369 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource 1370 Names for Device Identifiers", draft-arkko-core-dev-urn-03 1371 (work in progress), July 2012. 1373 [I-D.greevenbosch-appsawg-cbor-cddl] 1374 Vigano, C. and H. Birkholz, "CBOR data definition language 1375 (CDDL): a notational convention to express CBOR data 1376 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 1377 in progress), March 2016. 1379 [I-D.ietf-core-links-json] 1380 Li, K., Rahman, A., and D. Bormann, "Representing CoRE 1381 Formats in JSON and CBOR", draft-ietf-core-links-json-05 1382 (work in progress), April 2016. 1384 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1385 May 1997, . 1387 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1388 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1389 3986, DOI 10.17487/RFC3986, January 2005, 1390 . 1392 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1393 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 1394 10.17487/RFC4122, July 2005, 1395 . 1397 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1398 Address Text Representation", RFC 5952, DOI 10.17487/ 1399 RFC5952, August 2010, 1400 . 1402 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1403 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1404 . 1406 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1407 Considerations for IPv6 Address Generation Mechanisms", 1408 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1409 . 1411 [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units 1412 of Measure (UCUM)", Regenstrief Institute and Indiana 1413 University School of Informatics, 2013, 1414 . 1416 Appendix A. Links extension 1418 An extension to SenML to support links is expected to be registered 1419 and defined by [I-D.ietf-core-links-json]. 1421 The link extension can be an array of objects that can be used for 1422 additional information. Each object in the Link array is constrained 1423 to being a map of strings to strings with unique keys. 1425 The following shows an example of the links extension. 1427 [{"bn": "urn:dev:ow:10e2073a01080063/", 1428 "bt": 1320078429, 1429 "l": "[{\"href\":\"humidity\",\"foo\":\"bar1\"}", 1430 "n": "temperature", "v": 27.2, "u": "Cel" }, 1431 { "n": "humidity", "v": 80, "u": "%RH" } 1432 ] 1434 Authors' Addresses 1435 Cullen Jennings 1436 Cisco 1437 400 3rd Avenue SW 1438 Calgary, AB T2P 4H2 1439 Canada 1441 Phone: +1 408 421-9990 1442 Email: fluffy@iii.ca 1444 Zach Shelby 1445 ARM 1446 150 Rose Orchard 1447 San Jose 95134 1448 USA 1450 Phone: +1-408-203-9434 1451 Email: zach.shelby@arm.com 1453 Jari Arkko 1454 Ericsson 1455 Jorvas 02420 1456 Finland 1458 Email: jari.arkko@piuha.net 1460 Ari Keranen 1461 Ericsson 1462 Jorvas 02420 1463 Finland 1465 Email: ari.keranen@ericsson.com 1467 Carsten Bormann 1468 Universitaet Bremen TZI 1469 Postfach 330440 1470 Bremen D-28359 1471 Germany 1473 Phone: +49-421-218-63921 1474 Email: cabo@tzi.org