idnits 2.17.1 draft-ietf-core-senml-05.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2598 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-09 == Outdated reference: A later version (-10) exists of draft-ietf-core-links-json-06 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 5 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: September 14, 2017 ARM 6 J. Arkko 7 A. Keranen 8 Ericsson 9 C. Bormann 10 Universitaet Bremen TZI 11 March 13, 2017 13 Media Types for Sensor Measurement Lists (SenML) 14 draft-ietf-core-senml-05 16 Abstract 18 This specification defines media types for representing simple sensor 19 measurements and device parameters in the Sensor Measurement Lists 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 September 14, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Regular attributes . . . . . . . . . . . . . . . . . . . 6 68 4.3. Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Resolved Records . . . . . . . . . . . . . . . . . . . . 8 70 4.5. Associating Meta-data . . . . . . . . . . . . . . . . . . 8 71 5. JSON Representation (application/senml+json) . . . . . . . . 9 72 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 10 74 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 10 75 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 11 76 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 12 77 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 13 78 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 13 79 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 14 80 6. CBOR Representation (application/senml+cbor) . . . . . . . . 15 81 7. XML Representation (application/senml+xml) . . . . . . . . . 17 82 8. EXI Representation (application/senml+exi) . . . . . . . . . 19 83 9. Fragment Identification Methods . . . . . . . . . . . . . . . 22 84 9.1. Fragment Identification Examples . . . . . . . . . . . . 22 85 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 23 86 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26 89 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 29 90 12.3. Media Type Registration . . . . . . . . . . . . . . . . 30 91 12.3.1. senml+json Media Type Registration . . . . . . . . . 30 92 12.3.2. sensml+json Media Type Registration . . . . . . . . 32 93 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 33 94 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 34 95 12.3.5. senml+xml Media Type Registration . . . . . . . . . 36 96 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37 97 12.3.7. senml+exi Media Type Registration . . . . . . . . . 38 98 12.3.8. sensml+exi Media Type Registration . . . . . . . . . 40 99 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41 100 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41 101 13. Security Considerations . . . . . . . . . . . . . . . . . . . 42 102 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 103 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 104 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 105 16.1. Normative References . . . . . . . . . . . . . . . . . . 42 106 16.2. Informative References . . . . . . . . . . . . . . . . . 44 107 Appendix A. Links Extension . . . . . . . . . . . . . . . . . . 45 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 110 1. Overview 112 Connecting sensors to the Internet is not new, and there have been 113 many protocols designed to facilitate it. This specification defines 114 new media types for carrying simple sensor information in a protocol 115 such as HTTP or CoAP. This format was designed so that processors 116 with very limited capabilities could easily encode a sensor 117 measurement into the media type, while at the same time a server 118 parsing the data could relatively efficiently collect a large number 119 of sensor measurements. SenML can be used for a variety of data flow 120 models, most notably data feeds pushed from a sensor to a collector, 121 and the web resource model where the sensor is requested as a 122 resource representation (e.g., "GET /sensor/temperature"). 124 There are many types of more complex measurements and measurements 125 that this media type would not be suitable for. SenML strikes a 126 balance between having some information about the sensor carried with 127 the sensor data so that the data is self describing but it also tries 128 to make that a fairly minimal set of auxiliary information for 129 efficiency reason. Other information about the sensor can be 130 discovered by other methods such as using the CoRE Link Format 131 [RFC6690]. 133 SenML is defined by a data model for measurements and simple meta- 134 data about measurements and devices. The data is structured as a 135 single array that contains a series of SenML Records which can each 136 contain attributes such as an unique identifier for the sensor, the 137 time the measurement was made, the unit the measurement is in, and 138 the current value of the sensor. Serializations for this data model 139 are defined for JSON [RFC7159], CBOR [RFC7049], XML, and Efficient 140 XML Interchange (EXI) [W3C.REC-exi-20140211]. 142 For example, the following shows a measurement from a temperature 143 gauge encoded in the JSON syntax. 145 [ 146 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} 147 ] 149 In the example above, the array has a single SenML Record with a 150 measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a 151 current value of 23.1 degrees Celsius. 153 2. Requirements and Design Goals 155 The design goal is to be able to send simple sensor measurements in 156 small packets on mesh networks from large numbers of constrained 157 devices. Keeping the total size of payload under 80 bytes makes this 158 easy to use on a wireless mesh network. It is always difficult to 159 define what small code is, but there is a desire to be able to 160 implement this in roughly 1 KB of flash on a 8 bit microprocessor. 161 Experience with Google power meter and large scale deployments has 162 indicated that the solution needs to support allowing multiple 163 measurements to be batched into a single HTTP or CoAP request. This 164 "batch" upload capability allows the server side to efficiently 165 support a large number of devices. It also conveniently supports 166 batch transfers from proxies and storage devices, even in situations 167 where the sensor itself sends just a single data item at a time. The 168 multiple measurements could be from multiple related sensors or from 169 the same sensor but at different times. 171 The basic design is an array with a series of measurements. The 172 following example shows two measurements made at different times. 173 The value of a measurement is in the "v" tag, the time of a 174 measurement is in the "t" tag, the "n" tag has a unique sensor name, 175 and the unit of the measurement is carried in the "u" tag. 177 [ 178 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09, 179 "v":23.5}, 180 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09, 181 "v":23.6} 182 ] 184 To keep the messages small, it does not make sense to repeat the "n" 185 tag in each SenML Record so there is a concept of a Base Name which 186 is simply a string that is prepended to the Name field of all 187 elements in that record and any records that follow it. So a more 188 compact form of the example above is the following. 190 [ 191 {"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09, 192 "v":23.5}, 193 {"u":"Cel","t":1.276020091e+09, 194 "v":23.6} 195 ] 197 In the above example the Base Name is in the "bn" tag and the "n" 198 tags in each Record are the empty string so they are omitted. 200 Some devices have accurate time while others do not so SenML supports 201 absolute and relative times. Time is represented in floating point 202 as seconds and values greater than zero represent an absolute time 203 relative to the Unix epoch while values of 0 or less represent a 204 relative time in the past from the current time. A simple sensor 205 with no absolute wall clock time might take a measurement every 206 second, batch up 60 of them, and then send the batch to a server. It 207 would include the relative time each measurement was made compared to 208 the time the batch was sent in each SenML Record. The server might 209 have accurate NTP time and use the time it received the data, and the 210 relative offset, to replace the times in the SenML with absolute 211 times before saving the SenML Pack in a document database. 213 3. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in 218 [RFC2119]. 220 This document also uses the following terms: 222 SenML Record: One measurement or configuration instance in time 223 presented using the SenML data model. 225 SenML Pack: One or more SenML Records in an array structure. 227 4. SenML Structure and Semantics 229 Each SenML Pack carries a single array that represents a set of 230 measurements and/or parameters. This array contains a series of 231 SenML Records with several attributes described below. There are two 232 kind of attributes: base and regular. The base attributes can only 233 be included in the first SenML Record and they apply to the entries 234 in all Records. All base attributes are optional. Regular 235 attributes can be included in any SenML Record and apply only to that 236 Record. 238 4.1. Base attributes 240 Base Name: This is a string that is prepended to the names found in 241 the entries. 243 Base Time: A base time that is added to the time found in an entry. 245 Base Unit: A base unit that is assumed for all entries, unless 246 otherwise indicated. If a record does not contain a Unit value, 247 then the Base Unit is used. Otherwise the value found in the Unit 248 (if any) is used. 250 Base Value: A base value is added to the value found in an entry, 251 similar to Base Time. 253 Base Sum: A base sum is added to the sum found in an entry, similar 254 to Base Time. 256 Version: Version number of media type format. This attribute is an 257 optional positive integer and defaults to 5 if not present. [RFC 258 Editor: change the default value to 10 when this specification is 259 published as an RFC and remove this note] 261 4.2. Regular attributes 263 Name: Name of the sensor or parameter. When appended to the Base 264 Name attribute, this must result in a globally unique identifier 265 for the resource. The name is optional, if the Base Name is 266 present. If the name is missing, Base Name must uniquely identify 267 the resource. This can be used to represent a large array of 268 measurements from the same sensor without having to repeat its 269 identifier on every measurement. 271 Unit: Units for a measurement value. Optional. If the Record has 272 no Unit, the Base Unit is used as the Unit. Having no Unit and no 273 Base Unit is allowed. 275 Value Value of the entry. Optional if a Sum value is present, 276 otherwise required. Values are represented using basic data 277 types. This specification defines floating point numbers ("v" 278 field for "Value"), booleans ("vb" for "Boolean Value"), strings 279 ("vs" for "String Value") and binary data ("vd" for "Data Value"). 280 Exactly one value field MUST appear unless there is Sum field in 281 which case it is allowed to have no Value field. 283 Sum: Integrated sum of the values over time. Optional. This 284 attribute is in the units specified in the Unit value multiplied 285 by seconds. 287 Time: Time when value was recorded. Optional. 289 Update Time: An optional time in seconds that represents the maximum 290 time before this sensor will provide an updated reading for a 291 measurement. This can be used to detect the failure of sensors or 292 communications path from the sensor. 294 4.3. Considerations 296 The SenML format can be extended with further custom attributes. 297 Both new base and regular attributes are allowed. See Section 12.2 298 for details. Implementations MUST ignore attributes they don't 299 recognize. 301 Systems reading one of the objects MUST check for the Version 302 attribute. If this value is a version number larger than the version 303 which the system understands, the system SHOULD NOT use this object. 304 This allows the version number to indicate that the object contains 305 mandatory to understand attributes. New version numbers can only be 306 defined in an RFC that updates this specification or it successors. 308 The Name value is concatenated to the Base Name value to get the name 309 of the sensor. The resulting name needs to uniquely identify and 310 differentiate the sensor from all others. If the object is a 311 representation resulting from the request of a URI [RFC3986], then in 312 the absence of the Base Name attribute, this URI is used as the 313 default value of Base Name. Thus in this case the Name field needs 314 to be unique for that URI, for example an index or subresource name 315 of sensors handled by the URI. 317 Alternatively, for objects not related to a URI, a unique name is 318 required. In any case, it is RECOMMENDED that the full names are 319 represented as URIs or URNs [RFC2141]. One way to create a unique 320 name is to include some bit string that has guaranteed uniqueness 321 (such as a 1-wire address) that is assigned to the device. Some of 322 the examples in this draft use the device URN type as specified in 323 [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to 324 generate a unique name. Note that long-term stable unique 325 identifiers are problematic for privacy reasons [RFC7721] and should 326 be used with care or avoided. 328 The resulting concatenated name MUST consist only of characters out 329 of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 330 and it MUST start with a character out of the set "A" to "Z", "a" to 331 "z", or "0" to "9". This restricted character set was chosen so that 332 these names can be directly used as in other types of URI including 333 segments of an HTTP path with no special encoding and can be directly 334 used in many databases and analytic systems. [RFC5952] contains 335 advice on encoding an IPv6 address in a name. 337 If either the Base Time or Time value is missing, the missing 338 attribute is considered to have a value of zero. The Base Time and 339 Time values are added together to get the time of measurement. A 340 time of zero indicates that the sensor does not know the absolute 341 time and the measurement was made roughly "now". A negative value is 342 used to indicate seconds in the past from roughly "now". A positive 343 value is used to indicate the number of seconds, excluding leap 344 seconds, since the start of the year 1970 in UTC. 346 If only one of the Base Sum or Sum value is present, the missing 347 attribute is considered to have a value of zero. The Base Sum and 348 Sum values are added together to get the sum of measurement. If 349 neither the Base Sum or Sum are present, then the measurement does 350 not have a sum value. 352 Representing the statistical characteristics of measurements, such as 353 accuracy, can be very complex. Future specification may add new 354 attributes to provide better information about the statistical 355 properties of the measurement. 357 4.4. Resolved Records 359 Sometimes it is useful to be able to refer to a defined normalized 360 format for SenML records. This normalized format tends to get used 361 for big data applications and intermediate forms when converting to 362 other formats. 364 A SenML Record is referred to as "resolved" if it does not contain 365 any base values and has no relative times, but the base values of the 366 SenML Pack (if any) are applied to the Record. That is, name and 367 base name are concatenated, base time is added to the time of the 368 Record, if the Record did not contain Unit the Base Unit is applied 369 to the record, etc. In addition the records need to be in 370 chronological order. An example of this is show in Section 5.1.4. 372 Future specification that defines new base attributes need to specify 373 how the attribute is resolved. 375 4.5. Associating Meta-data 377 SenML is designed to carry the minimum dynamic information about 378 measurements, and for efficiency reasons does not carry significant 379 static meta-data about the device, object or sensors. Instead, it is 380 assumed that this meta-data is carried out of band. For web 381 resources using SenML Packs, this meta-data can be made available 382 using the CoRE Link Format [RFC6690]. The most obvious use of this 383 link format is to describe that a resource is available in a SenML 384 format in the first place. The relevant media type indicator is 385 included in the Content-Type (ct=) attribute. 387 5. JSON Representation (application/senml+json) 389 The SenML labels (JSON object member names) shown in Table 1 are used 390 in JSON SenML Record attributes. 392 +---------------+-------+---------+ 393 | Name | label | Type | 394 +---------------+-------+---------+ 395 | Base Name | bn | String | 396 | Base Time | bt | Number | 397 | Base Unit | bu | String | 398 | Base Value | bv | Number | 399 | Base Sum | bs | Number | 400 | Version | bver | Number | 401 | Name | n | String | 402 | Unit | u | String | 403 | Value | v | Number | 404 | String Value | vs | String | 405 | Boolean Value | vb | Boolean | 406 | Data Value | vd | String | 407 | Value Sum | s | Number | 408 | Time | t | Number | 409 | Update Time | ut | Number | 410 | Link | l | String | 411 +---------------+-------+---------+ 413 Table 1: JSON SenML Labels 415 The root content consists of an array with one JSON object for each 416 SenML Record. All the fields in the above table MAY occur in the 417 records with the type specified in the table. 419 Only the UTF-8 form of JSON is allowed. Characters in the String 420 Value are encoded using the escape sequences defined in [RFC7159]. 421 Octets in the Data Value are base64 encoded with URL safe alphabet as 422 defined in Section 5 of [RFC4648]. 424 Systems receiving measurements MUST be able to process the range of 425 floating point numbers that are representable as an IEEE double 426 precision floating point numbers [IEEE.754.1985]. The number of 427 significant digits in any measurement is not relevant, so a reading 428 of 1.1 has exactly the same semantic meaning as 1.10. If the value 429 has an exponent, the "e" MUST be in lower case. The mantissa SHOULD 430 be less than 19 characters long and the exponent SHOULD be less than 431 5 characters long. This allows time values to have better than micro 432 second precision over the next 100 years. 434 5.1. Examples 436 5.1.1. Single Datapoint 438 The following shows a temperature reading taken approximately "now" 439 by a 1-wire sensor device that was assigned the unique 1-wire address 440 of 10e2073a01080063: 442 [ 443 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} 444 ] 446 5.1.2. Multiple Datapoints 448 The following example shows voltage and current now, i.e., at an 449 unspecified time. 451 [ 452 {"bn":"urn:dev:ow:10e2073a01080063;","n":"voltage","u":"V","v":120.1}, 453 {"n":"current","u":"A","v":1.2} 454 ] 456 The next example is similar to the above one, but shows current at 457 Tue Jun 8 18:01:16.001 UTC 2010 and at each second for the previous 5 458 seconds. 460 [ 461 {"bn":"urn:dev:ow:10e2073a0108006;","bt":1.276020076001e+09, 462 "bu":"A","bver":5, 463 "n":"voltage","u":"V","v":120.1}, 464 {"n":"current","t":-5,"v":1.2}, 465 {"n":"current","t":-4,"v":1.3}, 466 {"n":"current","t":-3,"v":1.4}, 467 {"n":"current","t":-2,"v":1.5}, 468 {"n":"current","t":-1,"v":1.6}, 469 {"n":"current","v":1.7} 470 ] 472 Note that in some usage scenarios of SenML the implementations MAY 473 store or transmit SenML in a stream-like fashion, where data is 474 collected over time and continuously added to the object. This mode 475 of operation is optional, but systems or protocols using SenML in 476 this fashion MUST specify that they are doing this. SenML defines a 477 separate media type to indicate Sensor Streaming Measurement Lists 478 (SensML) for this usage (see Section 12.3.1). In this situation the 479 SensML stream can be sent and received in a partial fashion, i.e., a 480 measurement entry can be read as soon as the SenML Record is received 481 and not have to wait for the full SensML Stream to be complete. 483 For instance, the following stream of measurements may be sent via a 484 long lived HTTP POST from the producer of a SensML to the consumer of 485 that, and each measurement object may be reported at the time it was 486 measured: 488 [ 489 {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, 490 "bu":"%RH","v":21.2}, 491 {"t":10,"v":21.3}, 492 {"t":20,"v":21.4}, 493 {"t":30,"v":21.4}, 494 {"t":40,"v":21.5}, 495 {"t":50,"v":21.5}, 496 {"t":60,"v":21.5}, 497 {"t":70,"v":21.6}, 498 {"t":80,"v":21.7}, 499 ... 501 5.1.3. Multiple Measurements 503 The following example shows humidity measurements from a mobile 504 device with a 1-wire address 10e2073a01080063, starting at Mon Oct 31 505 13:24:24 UTC 2011. The device also provides position data, which is 506 provided in the same measurement or parameter array as separate 507 entries. Note time is used to for correlating data that belongs 508 together, e.g., a measurement and a parameter associated with it. 509 Finally, the device also reports extra data about its battery status 510 at a separate time. 512 [ 513 {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, 514 "bu":"%RH","v":20}, 515 {"u":"lon","v":24.30621}, 516 {"u":"lat","v":60.07965}, 517 {"t":60,"v":20.3}, 518 {"u":"lon","t":60,"v":24.30622}, 519 {"u":"lat","t":60,"v":60.07965}, 520 {"t":120,"v":20.7}, 521 {"u":"lon","t":120,"v":24.30623}, 522 {"u":"lat","t":120,"v":60.07966}, 523 {"u":"%EL","t":150,"v":98}, 524 {"t":180,"v":21.2}, 525 {"u":"lon","t":180,"v":24.30628}, 526 {"u":"lat","t":180,"v":60.07967} 527 ] 529 The size of this example represented in various forms, as well as 530 that form compressed with gzip is given in the following table. 532 +----------+------+-----------------+ 533 | Encoding | Size | Compressed Size | 534 +----------+------+-----------------+ 535 | JSON | 573 | 206 | 536 | XML | 649 | 235 | 537 | CBOR | 254 | 196 | 538 | EXI | 162 | 185 | 539 +----------+------+-----------------+ 541 Table 2: Size Comparisons 543 Note the EXI sizes are not using the schema guidance so the EXI 544 representation could be a bit smaller. 546 5.1.4. Resolved Data 548 The following shows the example from the previous section show in 549 resolved format. 551 [ 552 {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, 553 "v":20}, 554 {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, 555 "v":24.30621}, 556 {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09, 557 "v":60.07965}, 558 {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09, 559 "v":20.3}, 560 {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09, 561 "v":24.30622}, 562 {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09, 563 "v":60.07965}, 564 {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09, 565 "v":20.7}, 566 {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09, 567 "v":24.30623}, 568 {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09, 569 "v":60.07966}, 570 {"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09, 571 "v":98}, 572 {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09, 573 "v":21.2}, 574 {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09, 575 "v":24.30628}, 576 {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09, 577 "v":60.07967} 578 ] 580 5.1.5. Multiple Data Types 582 The following example shows a sensor that returns different data 583 types. 585 [ 586 {"bn":"urn:dev:ow:10e2073a01080063;","n":"temp","u":"Cel","v":23.1}, 587 {"n":"label","vs":"Machine Room"}, 588 {"n":"open","vb":false}, 589 {"n":"nfv-reader","vd":"aGkgCg=="} 590 ] 592 5.1.6. Collection of Resources 594 The following example shows how to query one device that can provide 595 multiple measurements. The example assumes that a client has fetched 596 information from a device at 2001:db8::2 by performing a GET 597 operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, 598 and has gotten two separate values as a result, a temperature and 599 humidity measurement. 601 [ 602 {"bn":"http://[2001:db8::2]/","bt":1.320078429e+09, 603 "n":"temperature","u":"Cel","v":27.2}, 604 {"n":"humidity","u":"%RH","v":80} 605 ] 607 5.1.7. Setting an Actuator 609 The following example show the SenML that could be used to set the 610 current set point of a typical residential thermostat which has a 611 temperature set point, a switch to turn on and off the heat, and a 612 switch to turn on the fan override. 614 [ 615 {"bn":"urn:dev:ow:10e2073a01080063;"}, 616 {"n":"temp","u":"Cel","v":23.1}, 617 {"n":"heat","u":"/","v":1}, 618 {"n":"fan","u":"/","v":0} 619 ] 621 In the following example two different lights are turned on. It is 622 assumed that the lights are on a 802.1BA network that can guarantee 623 delivery of the messages to the two lights within 15 ms and uses 624 802.1AS for time synchronization. The controller has set the time of 625 the lights coming on to 20 ms in the future from the current time. 626 This allows both lights to receive the message, wait till that time, 627 then apply the switch command so that both lights come on at the same 628 time. 630 [ 631 {"bt":1.320078429e+09,"bu":"/","n":"http://[2001:db8::3]/","v":1}, 632 {"n":"http://[2001:db8::4]/","v":1} 633 ] 635 The following shows two lights being turned off using a non 636 deterministic network that has a high odds of delivering a message in 637 less than 100 ms and uses NTP for time synchronization. The current 638 time is 1320078429. The user has just turned off a light switch 639 which is turning off two lights. Both lights are dimmed to 50% 640 brightness immediately to give the user instant feedback that 641 something is changing. However given the network, the lights will 642 probably dim at somewhat different times. Then 100 ms in the future, 643 both lights will go off at the same time. The instant but not 644 synchronized dimming gives the user the sensation of quick responses 645 and the timed off 100 ms in the future gives the perception of both 646 lights going off at the same time. 648 [ 649 {"bt":1.320078429e+09,"bu":"/","n":"http://[2001:db8::3]/","v":0.5}, 650 {"n":"http://[2001:db8::4]/","v":0.5}, 651 {"n":"http://[2001:db8::3]/","t":0.1,"v":0}, 652 {"n":"http://[2001:db8::4]/","t":0.1,"v":0} 653 ] 655 6. CBOR Representation (application/senml+cbor) 657 The CBOR [RFC7049] representation is equivalent to the JSON 658 representation, with the following changes: 660 o For JSON Numbers, the CBOR representation can use integers, 661 floating point numbers, or decimal fractions (CBOR Tag 4); however 662 a representation SHOULD be chosen such that when the CBOR value is 663 converted back to an IEEE double precision floating point value, 664 it has exactly the same value as the original Number. For the 665 version number, only an unsigned integer is allowed. 667 o Characters in the String Value are encoded using a definite length 668 text string (type 3). Octets in the Data Value are encoded using 669 a definite length byte string (type 2) . 671 o For compactness, the CBOR representation uses integers for the map 672 keys defined in Table 3. This table is conclusive, i.e., there is 673 no intention to define any additional integer map keys; any 674 extensions will use string map keys. This allows translators 675 converting between CBOR and JSON representations to convert also 676 all future labels without needing to update implementations. 678 +---------------+-------+------------+ 679 | Name | Label | CBOR Label | 680 +---------------+-------+------------+ 681 | Version | bver | -1 | 682 | Base Name | bn | -2 | 683 | Base Time | bt | -3 | 684 | Base Units | bu | -4 | 685 | Base Value | bv | -5 | 686 | Base Sum | bs | -6 | 687 | Name | n | 0 | 688 | Units | u | 1 | 689 | Value | v | 2 | 690 | String Value | vs | 3 | 691 | Boolean Value | vb | 4 | 692 | Value Sum | s | 5 | 693 | Time | t | 6 | 694 | Update Time | ut | 7 | 695 | Data Value | vd | 8 | 696 | Link | l | 9 | 697 +---------------+-------+------------+ 699 Table 3: CBOR representation: integers for map keys 701 o For streaming SensML in CBOR representation, the array containing 702 the records SHOULD be an CBOR indefinite length array while for 703 non streaming SenML, a definite length array MUST be used. 705 The following example shows a dump of the CBOR example for the same 706 sensor measurement as in Section 5.1.2. 708 0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:| 709 0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3b |10e2073a0108006;| 710 0020 22 fb 41 d3 03 a1 5b 00 10 62 23 61 41 20 05 00 |".A...[..b#aA ..| 711 0030 67 76 6f 6c 74 61 67 65 01 61 56 02 fb 40 5e 06 |gvoltage.aV..@^.| 712 0040 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 06 |fffff..gcurrent.| 713 0050 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 75 |$..?.333333..gcu| 714 0060 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc cc |rrent.#..?......| 715 0070 cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb 3f |...gcurrent."..?| 716 0080 f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e |.ffffff..gcurren| 717 0090 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 6e |t.!..>...gcurren| 718 00a0 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 67 |t. ..?.........g| 719 00b0 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 33 |current....?.333| 720 00c0 33 33 33 |333| 721 00c3 723 7. XML Representation (application/senml+xml) 725 A SenML Pack or Stream can also be represented in XML format as 726 defined in this section. 728 Only the UTF-8 form of XML is allowed. Characters in the String 729 Value are encoded using the escape sequences defined in [RFC7159]. 730 Octets in the Data Value are base64 encoded with URL safe alphabet as 731 defined in Section 5 of [RFC4648]. 733 The following example shows an XML example for the same sensor 734 measurement as in Section 5.1.2. 736 737 739 740 741 742 743 744 745 747 The SenML Stream is represented as a sensml tag that contains a 748 series of senml tags for each SenML Record. The SenML Fields are 749 represents as XML attributes. The following table shows the mapping 750 of the SenML labels, which are used for the attribute name, to the 751 attribute types used in the XML senml tags. 753 +---------------+-------+---------+ 754 | Name | Label | Type | 755 +---------------+-------+---------+ 756 | Base Name | bn | string | 757 | Base Time | bt | double | 758 | Base Unit | bu | string | 759 | Base Value | bv | double | 760 | Base Sum | bs | double | 761 | Base Version | bver | int | 762 | Name | n | string | 763 | Unit | u | string | 764 | Value | v | double | 765 | String Value | vs | string | 766 | Data Value | vd | string | 767 | Boolean Value | vb | boolean | 768 | Value Sum | s | double | 769 | Time | t | double | 770 | Update Time | ut | double | 771 | Link | l | string | 772 +---------------+-------+---------+ 774 Table 4: XML SenML Labels 776 The RelaxNG schema for the XML is: 778 default namespace = "urn:ietf:params:xml:ns:senml" 779 namespace rng = "http://relaxng.org/ns/structure/1.0" 781 senml = element senml { 782 attribute bn { xsd:string }?, 783 attribute bt { xsd:double }?, 784 attribute bv { xsd:double }?, 785 attribute bs { xsd:double }?, 786 attribute bu { xsd:string }?, 787 attribute bver { xsd:int }?, 789 attribute l { xsd:string }?, 791 attribute n { xsd:string }?, 792 attribute s { xsd:double }?, 793 attribute t { xsd:double }?, 794 attribute u { xsd:string }?, 795 attribute ut { xsd:double }?, 797 attribute v { xsd:double }?, 798 attribute vb { xsd:boolean }?, 799 attribute vs { xsd:string }?, 800 attribute vd { xsd:string }? 801 } 803 sensml = 804 element sensml { 805 senml+ 806 } 808 start = sensml 810 8. EXI Representation (application/senml+exi) 812 For efficient transmission of SenML over e.g. a constrained network, 813 Efficient XML Interchange (EXI) can be used. This encodes the XML 814 Schema structure of SenML into binary tags and values rather than 815 ASCII text. An EXI representation of SenML SHOULD be made using the 816 strict schema-mode of EXI. This mode however does not allow tag 817 extensions to the schema, and therefore any extensions will be lost 818 in the encoding. For uses where extensions need to be preserved in 819 EXI, the non-strict schema mode of EXI MAY be used. 821 The EXI header MUST include an "EXI Options", as defined in 822 [W3C.REC-exi-20140211], with an schemaId set to the value of "a" 823 indicating the schema provided in this specification. Future 824 revisions to the schema can change the value of the schemaId to allow 825 for backwards compatibility. When the data will be transported over 826 CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes 827 things larger and is redundant to information provided in the 828 Content-Type header. 830 The following is the XSD Schema to be used for strict schema guided 831 EXI processing. It is generated from the RelaxNG. 833 834 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 867 The following shows a hexdump of the EXI produced from encoding the 868 following XML example. Note this example is the same information as 869 the first example in Section 5.1.2 in JSON format. 871 872 874 875 877 Which compresses with EXI to the following displayed in hexdump: 879 0000 a0 30 0d 84 80 79 d5 c9 b8 e9 91 95 d8 e9 bd dc |.0...y..........| 880 0010 e8 c4 c1 94 c8 c0 dc cd 84 c0 c4 c0 e0 c0 c0 d8 |................| 881 0020 cc ed 82 5d 9b db 1d 18 59 d9 48 0d 58 ac 42 60 |...]....Y.H.X.B`| 882 0030 18 e1 2c 6e ae 4e 4c ad ce 84 06 82 41 90 0e |..,n.NL.....A..| 883 003f 885 The above example used the bit packed form of EXI but it is also 886 possible to use a byte packed form of EXI which can makes it easier 887 for a simple sensor to produce valid EXI without really implementing 888 EXI. Consider the example of a temperature sensor that produces a 889 value in tenths of degrees Celsius over a range of 0.0 to 55.0. It 890 would produce an XML SenML file such as: 892 893 894 896 The compressed form, using the byte alignment option of EXI, for the 897 above XML is the following: 899 0000 a0 00 48 80 6c 20 01 07 1d 75 72 6e 3a 64 65 76 |..H.l ...urn:dev| 900 0010 3a 6f 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 |:ow:10e2073a0108| 901 0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| 902 0030 01 |.| 903 0031 905 A small temperature sensor devices that only generates this one EXI 906 file does not really need an full EXI implementation. It can simply 907 hard code the output replacing the 1-wire device ID starting at byte 908 0x20 and going to byte 0x2F with it's device ID, and replacing the 909 value "0xe7 0x01" at location 0x37 and 0x38 with the current 910 temperature. The EXI Specification [W3C.REC-exi-20140211] contains 911 the full information 'on how floating point numbers are represented, 912 but for the purpose of this sensor, the temperature can be converted 913 to an integer in tenths of degrees (231 in this example). EXI stores 914 7 bits of the integer in each byte with the top bit set to one if 915 there are further bytes. So the first bytes at is set to low 7 bits 916 of the integer temperature in tenths of degrees plus 0x80. In this 917 example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the 918 integer temperature in tenths of degrees right shifted 7 bits. In 919 this example 231 >> 7 = 0x01. 921 9. Fragment Identification Methods 923 A SenML Pack typically consists of multiple SenML Records and for 924 some applications it may be useful to be able to refer with a 925 Fragment Identifier to a single record, or a set of records, in a 926 Pack. The fragment identifier is only interpreted by a client and 927 does not impact retrieval of a representation. The SenML Fragment 928 Identification is modeled after CSV Fragment Identifiers [RFC7111]. 930 To select a single SenML Record, the "rec" scheme followed by a 931 single number is used. For the purpose of numbering records, the 932 first record is at position 1. A range of records can be selected by 933 giving the first and the last record number separated by a '-' 934 character. Instead of the second number, the "*" character can be 935 used to indicate the last Senml Record in the Pack. A set of records 936 can also be selected using a comma separated list of record positions 937 or ranges. 939 (We use the term "selecting a record" for identifying it as part of 940 the fragment, not in the sense of isolating it from the Pack -- the 941 record still needs to be interpreted as part of the Pack, e.g., using 942 the base values defined in record 1.) 944 9.1. Fragment Identification Examples 946 The 3rd SenML Record from "coap://example.com/temp" resource can be 947 selected with: 949 coap://example.com/temp#rec=3 951 Records from 3rd to 6th can be selected with: 953 coap://example.com/temp#rec=3-6 955 Records from 19th to the last can be selected with: 957 coap://example.com/temp#rec=19-* 959 The 3rd and 5th record can be selected with: 961 coap://example.com/temp#rec=3,5 963 To select the Records from third to fifth, the 10th record, and all 964 from 19th to the last: 966 coap://example.com/temp#rec=3-5,10,19-* 968 10. Usage Considerations 970 The measurements support sending both the current value of a sensor 971 as well as the an integrated sum. For many types of measurements, 972 the sum is more useful than the current value. For example, an 973 electrical meter that measures the energy a given computer uses will 974 typically want to measure the cumulative amount of energy used. This 975 is less prone to error than reporting the power each second and 976 trying to have something on the server side sum together all the 977 power measurements. If the network between the sensor and the meter 978 goes down over some period of time, when it comes back up, the 979 cumulative sum helps reflect what happened while the network was 980 down. A meter like this would typically report a measurement with 981 the units set to watts, but it would put the sum of energy used in 982 the "s" attribute of the measurement. It might optionally include 983 the current power in the "v" attribute. 985 While the benefit of using the integrated sum is fairly clear for 986 measurements like power and energy, it is less obvious for something 987 like temperature. Reporting the sum of the temperature makes it easy 988 to compute averages even when the individual temperature values are 989 not reported frequently enough to compute accurate averages. 990 Implementors are encouraged to report the cumulative sum as well as 991 the raw value of a given sensor. 993 Applications that use the cumulative sum values need to understand 994 they are very loosely defined by this specification, and depending on 995 the particular sensor implementation may behave in unexpected ways. 996 Applications should be able to deal with the following issues: 998 1. Many sensors will allow the cumulative sums to "wrap" back to 999 zero after the value gets sufficiently large. 1001 2. Some sensors will reset the cumulative sum back to zero when the 1002 device is reset, loses power, or is replaced with a different 1003 sensor. 1005 3. Applications cannot make assumptions about when the device 1006 started accumulating values into the sum. 1008 Typically applications can make some assumptions about specific 1009 sensors that will allow them to deal with these problems. A common 1010 assumption is that for sensors whose measurement values are always 1011 positive, the sum should never get smaller; so if the sum does get 1012 smaller, the application will know that one of the situations listed 1013 above has happened. 1015 11. CDDL 1017 For reference, the JSON and CBOR representations can be described 1018 with the common CDDL [I-D.greevenbosch-appsawg-cbor-cddl] 1019 specification in Figure 1. 1021 SenML-Pack = [initial-record, * follow-on-record] 1023 initial-record = initial-defined .and initial-generic 1024 follow-on-record = follow-on-defined .and follow-on-generic 1026 ; first do a specification of the labels as defined: 1028 initial-defined = { 1029 ? bn => tstr, ; Base Name 1030 ? bt => numeric, ; Base Time 1031 ? bu => tstr, ; Base Units 1032 ? bv => numeric, ; Base value 1033 ? bs => numeric, ; Base sum 1034 ? bver => uint, ; Base Version 1035 follow-on-defined-group, 1036 + base-key-value-pair 1037 } 1039 follow-on-defined-group = ( 1040 ? n => tstr, ; Name 1041 ? u => tstr, ; Units 1042 ? s => numeric, ; Value Sum 1043 ? t => numeric, ; Time 1044 ? ut => numeric, ; Update Time 1045 ? l => tstr, ; Link 1046 * key-value-pair, 1047 ? ( v => numeric // ; Numeric Value 1048 vs => tstr // ; String Value 1049 vb => bool // ; Boolean Value 1050 vd => binary-value ) ; Data Value 1051 ) 1052 follow-on-defined = { follow-on-defined-group } 1054 ; now define the generic versions 1056 initial-generic = { 1057 follow-on-generic-group, 1058 * base-key-value-pair, 1059 } 1061 follow-on-generic-group = ( 1062 + key-value-pair, 1064 ) 1065 follow-on-generic = { follow-on-generic-group } 1067 key-value-pair = ( non-b-label => value ) 1069 base-key-value-pair = ( b-label => value ) 1071 non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint 1072 b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint 1074 value = tstr / binary-value / numeric / bool 1075 numeric = number / decfrac 1077 Figure 1: Common CDDL specification for CBOR and JSON SenML 1079 For JSON, we use text labels and base64url-encoded binary data 1080 (Figure 2). 1082 bver = "bver" n = "n" s = "s" 1083 bn = "bn" u = "u" t = "t" 1084 bt = "bt" v = "v" ut = "ut" 1085 bu = "bu" vs = "vs" vd = "vd" 1086 bv = "bv" vb = "vb" l = "l" 1087 bs = "bs" 1089 binary-value = tstr ; base64url encoded 1091 Figure 2: JSON-specific CDDL specification for SenML 1093 For CBOR, we use integer labels and native binary data (Figure 3). 1095 bver = -1 n = 0 s = 5 1096 bn = -2 u = 1 t = 6 1097 bt = -3 v = 2 ut = 7 1098 bu = -4 vs = 3 vd = 8 1099 bv = -5 vb = 4 l = 9 1100 bs = -6 1102 binary-value = bstr 1104 Figure 3: CBOR-specific CDDL specification for SenML 1106 12. IANA Considerations 1108 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 1109 the RFC number of this specification. 1111 12.1. Units Registry 1113 IANA will create a registry of SenML unit symbols. The primary 1114 purpose of this registry is to make sure that symbols uniquely map to 1115 give type of measurement. Definitions for many of these units can be 1116 found in location such as [NIST811] and [BIPM]. Units marked with an 1117 asterisk are NOT RECOMMENDED to be produced by new implementations, 1118 but are in active use and SHOULD be implemented by consumers that can 1119 use the related base units. 1121 +----------+------------------------------------+-------+-----------+ 1122 | Symbol | Description | Type | Reference | 1123 +----------+------------------------------------+-------+-----------+ 1124 | m | meter | float | RFC-AAAA | 1125 | kg | kilogram | float | RFC-AAAA | 1126 | g | gram* | float | RFC-AAAA | 1127 | s | second | float | RFC-AAAA | 1128 | A | ampere | float | RFC-AAAA | 1129 | K | kelvin | float | RFC-AAAA | 1130 | cd | candela | float | RFC-AAAA | 1131 | mol | mole | float | RFC-AAAA | 1132 | Hz | hertz | float | RFC-AAAA | 1133 | rad | radian | float | RFC-AAAA | 1134 | sr | steradian | float | RFC-AAAA | 1135 | N | newton | float | RFC-AAAA | 1136 | Pa | pascal | float | RFC-AAAA | 1137 | J | joule | float | RFC-AAAA | 1138 | W | watt | float | RFC-AAAA | 1139 | C | coulomb | float | RFC-AAAA | 1140 | V | volt | float | RFC-AAAA | 1141 | F | farad | float | RFC-AAAA | 1142 | Ohm | ohm | float | RFC-AAAA | 1143 | S | siemens | float | RFC-AAAA | 1144 | Wb | weber | float | RFC-AAAA | 1145 | T | tesla | float | RFC-AAAA | 1146 | H | henry | float | RFC-AAAA | 1147 | Cel | degrees Celsius | float | RFC-AAAA | 1148 | lm | lumen | float | RFC-AAAA | 1149 | lx | lux | float | RFC-AAAA | 1150 | Bq | becquerel | float | RFC-AAAA | 1151 | Gy | gray | float | RFC-AAAA | 1152 | Sv | sievert | float | RFC-AAAA | 1153 | kat | katal | float | RFC-AAAA | 1154 | m2 | square meter (area) | float | RFC-AAAA | 1155 | m3 | cubic meter (volume) | float | RFC-AAAA | 1156 | l | liter (volume)* | float | RFC-AAAA | 1157 | m/s | meter per second (velocity) | float | RFC-AAAA | 1158 | m/s2 | meter per square second | float | RFC-AAAA | 1159 | | (acceleration) | | | 1160 | m3/s | cubic meter per second (flow rate) | float | RFC-AAAA | 1161 | l/s | liter per second (flow rate)* | float | RFC-AAAA | 1162 | W/m2 | watt per square meter (irradiance) | float | RFC-AAAA | 1163 | cd/m2 | candela per square meter | float | RFC-AAAA | 1164 | | (luminance) | | | 1165 | bit | bit (information content) | float | RFC-AAAA | 1166 | bit/s | bit per second (data rate) | float | RFC-AAAA | 1167 | lat | degrees latitude (note 2) | float | RFC-AAAA | 1168 | lon | degrees longitude (note 2) | float | RFC-AAAA | 1169 | pH | pH value (acidity; logarithmic | float | RFC-AAAA | 1170 | | quantity) | | | 1171 | dB | decibel (logarithmic quantity) | float | RFC-AAAA | 1172 | Bspl | bel (sound pressure level; | float | RFC-AAAA | 1173 | | logarithmic quantity)* | | | 1174 | count | 1 (counter value) | float | RFC-AAAA | 1175 | / | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | 1176 | | note 1) | | | 1177 | % | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | 1178 | | note 1)* | | | 1179 | %RH | Percentage (Relative Humidity) | float | RFC-AAAA | 1180 | %EL | Percentage (remaining battery | float | RFC-AAAA | 1181 | | energy level) | | | 1182 | EL | seconds (remaining battery energy | float | RFC-AAAA | 1183 | | level) | | | 1184 | 1/s | 1 per second (event rate) | float | RFC-AAAA | 1185 | 1/min | 1 per minute (event rate, "rpm")* | float | RFC-AAAA | 1186 | beat/min | 1 per minute (Heart rate in beats | float | RFC-AAAA | 1187 | | per minute)* | | | 1188 | beats | 1 (Cumulative number of heart | float | RFC-AAAA | 1189 | | beats)* | | | 1190 +----------+------------------------------------+-------+-----------+ 1192 Table 5 1194 o Note 1: A value of 0.0 indicates the switch is off while 1.0 1195 indicates on and 0.5 would be half on. The preferred name of this 1196 unit is "/". For historical reasons, the name "%" is also 1197 provided for the same unit - but note that while that name 1198 strongly suggests a percentage (0..100) -- it is however NOT a 1199 percentage, but the absolute ratio! 1201 o Note 2: Assumed to be in WGS84 unless another reference frame is 1202 known for the sensor. 1204 New entries can be added to the registration by either Expert Review 1205 or IESG Approval as defined in [RFC5226]. Experts should exercise 1206 their own good judgment but need to consider the following 1207 guidelines: 1209 1. There needs to be a real and compelling use for any new unit to 1210 be added. 1212 2. Units should define the semantic information and be chosen 1213 carefully. Implementors need to remember that the same word may 1214 be used in different real-life contexts. For example, degrees 1215 when measuring latitude have no semantic relation to degrees 1216 when measuring temperature; thus two different units are needed. 1218 3. These measurements are produced by computers for consumption by 1219 computers. The principle is that conversion has to be easily be 1220 done when both reading and writing the media type. The value of 1221 a single canonical representation outweighs the convenience of 1222 easy human representations or loss of precision in a conversion. 1224 4. Use of SI prefixes such as "k" before the unit is not 1225 recommended. Instead one can represent the value using 1226 scientific notation such a 1.2e3. The "kg" unit is exception to 1227 this rule since it is an SI base unit; the "g" unit is provided 1228 for legacy compatibility. 1230 5. For a given type of measurement, there will only be one unit 1231 type defined. So for length, meters are defined and other 1232 lengths such as mile, foot, light year are not allowed. For 1233 most cases, the SI unit is preferred. 1235 6. Symbol names that could be easily confused with existing common 1236 units or units combined with prefixes should be avoided. For 1237 example, selecting a unit name of "mph" to indicate something 1238 that had nothing to do with velocity would be a bad choice, as 1239 "mph" is commonly used to mean miles per hour. 1241 7. The following should not be used because the are common SI 1242 prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, 1243 y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 1245 8. The following units should not be used as they are commonly used 1246 to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 1247 Oe, Gb, sb, Lmb, mph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 1248 BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 1250 9. The unit names are case sensitive and the correct case needs to 1251 be used, but symbols that differ only in case should not be 1252 allocated. 1254 10. A number after a unit typically indicates the previous unit 1255 raised to that power, and the / indicates that the units that 1256 follow are the reciprocal. A unit should have only one / in the 1257 name. 1259 11. A good list of common units can be found in the Unified Code for 1260 Units of Measure [UCUM]. 1262 12.2. SenML Label Registry 1264 IANA will create a new registry for SenML labels. The initial 1265 content of the registry is: 1267 +---------------+-------+------+----------+----+---------+ 1268 | Name | Label | CBOR | XML Type | ID | Note | 1269 +---------------+-------+------+----------+----+---------+ 1270 | Base Name | bn | -2 | string | a | RFCXXXX | 1271 | Base Sum | bs | -6 | double | a | RFCXXXX | 1272 | Base Time | bt | -3 | double | a | RFCXXXX | 1273 | Base Unit | bu | -4 | string | a | RFCXXXX | 1274 | Base Value | bv | -5 | double | a | RFCXXXX | 1275 | Base Version | bver | -1 | int | a | RFCXXXX | 1276 | Boolean Value | vb | 4 | boolean | a | RFCXXXX | 1277 | Data Value | vd | 8 | string | a | RFCXXXX | 1278 | Name | n | 0 | string | a | RFCXXXX | 1279 | String Value | vs | 3 | string | a | RFCXXXX | 1280 | Time | t | 6 | double | a | RFCXXXX | 1281 | Unit | u | 1 | string | a | RFCXXXX | 1282 | Update Time | ut | 7 | double | a | RFCXXXX | 1283 | Value | v | 2 | double | a | RFCXXXX | 1284 | Value Sum | s | 5 | double | a | RFCXXXX | 1285 | Link | l | 9 | string | a | RFCXXXX | 1286 +---------------+-------+------+----------+----+---------+ 1288 Table 6: SenML Labels 1290 Note to RFC Editor. Please replace RFCXXXX with the number for this 1291 RFC. 1293 All new entries must define the Label Name, Label, and XML Type but 1294 the CBOR labels SHOULD be left empty as CBOR will use the string 1295 encoding for any new labels. The ID fields contains the EXI schemaId 1296 value of the first Schema which includes this label or is empty if 1297 this label was not intended for use with EXI. The Note field SHOULD 1298 contain information about where to find out more information about 1299 this label. 1301 The JSON, CBOR, and EXI types are derived from the XML type. All XML 1302 numeric types such as double, float, integer and int become a JSON 1303 Number. XML boolean and string become a JSON Boolean and String 1304 respectively. CBOR represents numeric values with a CBOR type that 1305 does not loose any information from the JSON value. EXI uses the XML 1306 types. 1308 New entries can be added to the registration by either Expert Review 1309 or IESG Approval as defined in [RFC5226]. Experts should exercise 1310 their own good judgment but need to consider that shorter labels 1311 should have more strict review. 1313 All new SenML labels that have "base" semantics (see Section 4.1) 1314 MUST start with character 'b'. Regular labels MUST NOT start with 1315 that character. 1317 Extensions that add a label that is intended for use with XML need to 1318 create a new RelaxNG scheme that includes all the labels in the IANA 1319 registry. 1321 Extensions that add a label that is intended for use with EXI need to 1322 create a new XSD Schema that includes all the labels in the IANA 1323 registry then allocate a new EXI schemaId value. Moving to the next 1324 letter in the alphabet is the suggested way to create the new value 1325 for the EXI schemaId. Any labels with previously blank ID values 1326 SHOULD be updated in the IANA table to have their ID set to this new 1327 schemaId value. 1329 12.3. Media Type Registration 1331 The following registrations are done following the procedure 1332 specified in [RFC6838] and [RFC7303]. Clipboard formats are defined 1333 for the JSON and XML form of lists but do not make sense for streams 1334 or other formats. 1336 Note to RFC Editor - please remove this paragraph. Note that a 1337 request for media type review for senml+json was sent to the media- 1338 types@iana.org on Sept 21, 2010. A second request for all the types 1339 was sent on October 31, 2016. 1341 12.3.1. senml+json Media Type Registration 1343 Type name: application 1345 Subtype name: senml+json 1347 Required parameters: none 1348 Optional parameters: none 1350 Encoding considerations: Must be encoded as using a subset of the 1351 encoding allowed in [RFC7159]. See RFC-AAAA for details. This 1352 simplifies implementation of very simple system and does not impose 1353 any significant limitations as all this data is meant for machine to 1354 machine communications and is not meant to be human readable. 1356 Security considerations: Sensor data can contain a wide range of 1357 information ranging from information that is very public, such the 1358 outside temperature in a given city, to very private information that 1359 requires integrity and confidentiality protection, such as patient 1360 health information. This format does not provide any security and 1361 instead relies on the transport protocol that carries it to provide 1362 security. Given applications need to look at the overall context of 1363 how this media type will be used to decide if the security is 1364 adequate. 1366 Interoperability considerations: Applications should ignore any JSON 1367 key value pairs that they do not understand. This allows backwards 1368 compatibility extensions to this specification. The "bver" field can 1369 be used to ensure the receiver supports a minimal level of 1370 functionality needed by the creator of the JSON object. 1372 Published specification: RFC-AAAA 1374 Applications that use this media type: The type is used by systems 1375 that report e.g., electrical power usage and environmental 1376 information such as temperature and humidity. It can be used for a 1377 wide range of sensor reporting systems. 1379 Fragment identifier considerations: Fragment identification for 1380 application/senml+json is supported by using fragment identifiers as 1381 specified by RFC-AAAA. 1383 Additional information: 1385 Magic number(s): none 1387 File extension(s): senml 1389 Windows Clipboard Name: "JSON Sensor Measurement List" 1391 Macintosh file type code(s): none 1393 Macintosh Universal Type Identifier code: org.ietf.senml-json 1394 conforms to public.text 1395 Person & email address to contact for further information: Cullen 1396 Jennings 1398 Intended usage: COMMON 1400 Restrictions on usage: None 1402 Author: Cullen Jennings 1404 Change controller: IESG 1406 12.3.2. sensml+json Media Type Registration 1408 Type name: application 1410 Subtype name: sensml+json 1412 Required parameters: none 1414 Optional parameters: none 1416 Encoding considerations: Must be encoded as using a subset of the 1417 encoding allowed in [RFC7159]. See RFC-AAAA for details. This 1418 simplifies implementation of very simple system and does not impose 1419 any significant limitations as all this data is meant for machine to 1420 machine communications and is not meant to be human readable. 1422 Security considerations: Sensor data can contain a wide range of 1423 information ranging from information that is very public, such the 1424 outside temperature in a given city, to very private information that 1425 requires integrity and confidentiality protection, such as patient 1426 health information. This format does not provide any security and 1427 instead relies on the transport protocol that carries it to provide 1428 security. Given applications need to look at the overall context of 1429 how this media type will be used to decide if the security is 1430 adequate. 1432 Interoperability considerations: Applications should ignore any JSON 1433 key value pairs that they do not understand. This allows backwards 1434 compatibility extensions to this specification. The "bver" field can 1435 be used to ensure the receiver supports a minimal level of 1436 functionality needed by the creator of the JSON object. 1438 Published specification: RFC-AAAA 1440 Applications that use this media type: The type is used by systems 1441 that report e.g., electrical power usage and environmental 1442 information such as temperature and humidity. It can be used for a 1443 wide range of sensor reporting systems. 1445 Fragment identifier considerations: Fragment identification for 1446 application/senml+json is supported by using fragment identifiers as 1447 specified by RFC-AAAA. 1449 Additional information: 1451 Magic number(s): none 1453 File extension(s): sensml 1455 Macintosh file type code(s): none 1457 Person & email address to contact for further information: Cullen 1458 Jennings 1460 Intended usage: COMMON 1462 Restrictions on usage: None 1464 Author: Cullen Jennings 1466 Change controller: IESG 1468 12.3.3. senml+cbor Media Type Registration 1470 Type name: application 1472 Subtype name: senml+cbor 1474 Required parameters: none 1476 Optional parameters: none 1478 Encoding considerations: Must be encoded as using [RFC7049]. See 1479 RFC-AAAA for details. 1481 Security considerations: Sensor data can contain a wide range of 1482 information ranging from information that is very public, such the 1483 outside temperature in a given city, to very private information that 1484 requires integrity and confidentiality protection, such as patient 1485 health information. This format does not provide any security and 1486 instead relies on the transport protocol that carries it to provide 1487 security. Given applications need to look at the overall context of 1488 how this media type will be used to decide if the security is 1489 adequate. 1491 Interoperability considerations: Applications should ignore any key 1492 value pairs that they do not understand. This allows backwards 1493 compatibility extensions to this specification. The "bver" field can 1494 be used to ensure the receiver supports a minimal level of 1495 functionality needed by the creator of the CBOR object. 1497 Published specification: RFC-AAAA 1499 Applications that use this media type: The type is used by systems 1500 that report e.g., electrical power usage and environmental 1501 information such as temperature and humidity. It can be used for a 1502 wide range of sensor reporting systems. 1504 Fragment identifier considerations: Fragment identification for 1505 application/senml+cbor is supported by using fragment identifiers as 1506 specified by RFC-AAAA. 1508 Additional information: 1510 Magic number(s): none 1512 File extension(s): senmlc 1514 Macintosh file type code(s): none 1516 Macintosh Universal Type Identifier code: org.ietf.senml-cbor 1517 conforms to public.data 1519 Person & email address to contact for further information: Cullen 1520 Jennings 1522 Intended usage: COMMON 1524 Restrictions on usage: None 1526 Author: Cullen Jennings 1528 Change controller: IESG 1530 12.3.4. sensml+cbor Media Type Registration 1532 Type name: application 1534 Subtype name: sensml+cbor 1536 Required parameters: none 1538 Optional parameters: none 1539 Encoding considerations: Must be encoded as using [RFC7049]. See 1540 RFC-AAAA for details. 1542 Security considerations: Sensor data can contain a wide range of 1543 information ranging from information that is very public, such the 1544 outside temperature in a given city, to very private information that 1545 requires integrity and confidentiality protection, such as patient 1546 health information. This format does not provide any security and 1547 instead relies on the transport protocol that carries it to provide 1548 security. Given applications need to look at the overall context of 1549 how this media type will be used to decide if the security is 1550 adequate. 1552 Interoperability considerations: Applications should ignore any key 1553 value pairs that they do not understand. This allows backwards 1554 compatibility extensions to this specification. The "bver" field can 1555 be used to ensure the receiver supports a minimal level of 1556 functionality needed by the creator of the CBOR object. 1558 Published specification: RFC-AAAA 1560 Applications that use this media type: The type is used by systems 1561 that report e.g., electrical power usage and environmental 1562 information such as temperature and humidity. It can be used for a 1563 wide range of sensor reporting systems. 1565 Fragment identifier considerations: Fragment identification for 1566 application/senml+cbor is supported by using fragment identifiers as 1567 specified by RFC-AAAA. 1569 Additional information: 1571 Magic number(s): none 1573 File extension(s): sensmlc 1575 Macintosh file type code(s): none 1577 Person & email address to contact for further information: Cullen 1578 Jennings 1580 Intended usage: COMMON 1582 Restrictions on usage: None 1584 Author: Cullen Jennings 1586 Change controller: IESG 1588 12.3.5. senml+xml Media Type Registration 1590 Type name: application 1592 Subtype name: senml+xml 1594 Required parameters: none 1596 Optional parameters: none 1598 Encoding considerations: Must be encoded as using 1599 [W3C.REC-xml-20081126]. See RFC-AAAA for details. 1601 Security considerations: Sensor data can contain a wide range of 1602 information ranging from information that is very public, such the 1603 outside temperature in a given city, to very private information that 1604 requires integrity and confidentiality protection, such as patient 1605 health information. This format does not provide any security and 1606 instead relies on the transport protocol that carries it to provide 1607 security. Given applications need to look at the overall context of 1608 how this media type will be used to decide if the security is 1609 adequate. 1611 Interoperability considerations: Applications should ignore any tags 1612 or attributes that they do not understand. This allows backwards 1613 compatibility extensions to this specification. The "bver" attribute 1614 in the senml tag can be used to ensure the receiver supports a 1615 minimal level of functionality needed by the creator of the XML. 1617 Published specification: RFC-AAAA 1619 Applications that use this media type: The type is used by systems 1620 that report e.g., electrical power usage and environmental 1621 information such as temperature and humidity. It can be used for a 1622 wide range of sensor reporting systems. 1624 Fragment identifier considerations: Fragment identification for 1625 application/senml+xml is supported by using fragment identifiers as 1626 specified by RFC-AAAA. 1628 Additional information: 1630 Magic number(s): none 1632 File extension(s): senmlx 1634 Windows Clipboard Name: "XML Sensor Measurement List" 1635 Macintosh file type code(s): none 1637 Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms 1638 to public.xml 1640 Person & email address to contact for further information: Cullen 1641 Jennings 1643 Intended usage: COMMON 1645 Restrictions on usage: None 1647 Author: Cullen Jennings 1649 Change controller: IESG 1651 12.3.6. sensml+xml Media Type Registration 1653 Type name: application 1655 Subtype name: sensml+xml 1657 Required parameters: none 1659 Optional parameters: none 1661 Encoding considerations: Must be encoded as using 1662 [W3C.REC-xml-20081126]. See RFC-AAAA for details. 1664 Security considerations: Sensor data can contain a wide range of 1665 information ranging from information that is very public, such the 1666 outside temperature in a given city, to very private information that 1667 requires integrity and confidentiality protection, such as patient 1668 health information. This format does not provide any security and 1669 instead relies on the transport protocol that carries it to provide 1670 security. Given applications need to look at the overall context of 1671 how this media type will be used to decide if the security is 1672 adequate. 1674 Interoperability considerations: Applications should ignore any tags 1675 or attributes that they do not understand. This allows backwards 1676 compatibility extensions to this specification. The "bver" attribute 1677 in the senml tag can be used to ensure the receiver supports a 1678 minimal level of functionality needed by the creator of the XML. 1680 Published specification: RFC-AAAA 1681 Applications that use this media type: The type is used by systems 1682 that report e.g., electrical power usage and environmental 1683 information such as temperature and humidity. It can be used for a 1684 wide range of sensor reporting systems. 1686 Fragment identifier considerations: Fragment identification for 1687 application/senml+xml is supported by using fragment identifiers as 1688 specified by RFC-AAAA. 1690 Additional information: 1692 Magic number(s): none 1694 File extension(s): sensmlx 1696 Macintosh file type code(s): none 1698 Person & email address to contact for further information: Cullen 1699 Jennings 1701 Intended usage: COMMON 1703 Restrictions on usage: None 1705 Author: Cullen Jennings 1707 Change controller: IESG 1709 12.3.7. senml+exi Media Type Registration 1711 Type name: application 1713 Subtype name: senml+exi 1715 Required parameters: none 1717 Optional parameters: none 1719 Encoding considerations: Must be encoded as using 1720 [W3C.REC-exi-20140211]. See RFC-AAAA for details. 1722 Security considerations: Sensor data can contain a wide range of 1723 information ranging from information that is very public, such the 1724 outside temperature in a given city, to very private information that 1725 requires integrity and confidentiality protection, such as patient 1726 health information. This format does not provide any security and 1727 instead relies on the transport protocol that carries it to provide 1728 security. Given applications need to look at the overall context of 1729 how this media type will be used to decide if the security is 1730 adequate. 1732 Interoperability considerations: Applications should ignore any tags 1733 or attributes that they do not understand. This allows backwards 1734 compatibility extensions to this specification. The "bver" attribute 1735 in the senml tag can be used to ensure the receiver supports a 1736 minimal level of functionality needed by the creator of the XML. 1737 Further information on using schemas to guide the EXI can be found in 1738 RFC-AAAA. 1740 Published specification: RFC-AAAA 1742 Applications that use this media type: The type is used by systems 1743 that report e.g., electrical power usage and environmental 1744 information such as temperature and humidity. It can be used for a 1745 wide range of sensor reporting systems. 1747 Fragment identifier considerations: Fragment identification for 1748 application/senml+exi is supported by using fragment identifiers as 1749 specified by RFC-AAAA. 1751 Additional information: 1753 Magic number(s): none 1755 File extension(s): senmle 1757 Macintosh file type code(s): none 1759 Macintosh Universal Type Identifier code: org.ietf.senml-exi conforms 1760 to public.data 1762 Person & email address to contact for further information: Cullen 1763 Jennings 1765 Intended usage: COMMON 1767 Restrictions on usage: None 1769 Author: Cullen Jennings 1771 Change controller: IESG 1773 12.3.8. sensml+exi Media Type Registration 1775 Type name: application 1777 Subtype name: sensml+exi 1779 Required parameters: none 1781 Optional parameters: none 1783 Encoding considerations: Must be encoded as using 1784 [W3C.REC-exi-20140211]. See RFC-AAAA for details. 1786 Security considerations: Sensor data can contain a wide range of 1787 information ranging from information that is very public, such the 1788 outside temperature in a given city, to very private information that 1789 requires integrity and confidentiality protection, such as patient 1790 health information. This format does not provide any security and 1791 instead relies on the transport protocol that carries it to provide 1792 security. Given applications need to look at the overall context of 1793 how this media type will be used to decide if the security is 1794 adequate. 1796 Interoperability considerations: Applications should ignore any tags 1797 or attributes that they do not understand. This allows backwards 1798 compatibility extensions to this specification. The "bver" attribute 1799 in the senml tag can be used to ensure the receiver supports a 1800 minimal level of functionality needed by the creator of the XML. 1801 Further information on using schemas to guide the EXI can be found in 1802 RFC-AAAA. 1804 Published specification: RFC-AAAA 1806 Applications that use this media type: The type is used by systems 1807 that report e.g., electrical power usage and environmental 1808 information such as temperature and humidity. It can be used for a 1809 wide range of sensor reporting systems. 1811 Fragment identifier considerations: Fragment identification for 1812 application/senml+exi is supported by using fragment identifiers as 1813 specified by RFC-AAAA. 1815 Additional information: 1817 Magic number(s): none 1819 File extension(s): sensmle 1820 Macintosh file type code(s): none 1822 Person & email address to contact for further information: Cullen 1823 Jennings 1825 Intended usage: COMMON 1827 Restrictions on usage: None 1829 Author: Cullen Jennings 1831 Change controller: IESG 1833 12.4. XML Namespace Registration 1835 This document registers the following XML namespaces in the IETF XML 1836 registry defined in [RFC3688]. 1838 URI: urn:ietf:params:xml:ns:senml 1840 Registrant Contact: The IESG. 1842 XML: N/A, the requested URIs are XML namespaces 1844 12.5. CoAP Content-Format Registration 1846 IANA is requested to assign CoAP Content-Format IDs for the SenML 1847 media types in the "CoAP Content-Formats" sub-registry, within the 1848 "CoRE Parameters" registry [RFC7252]. All IDs are assigned from the 1849 "Expert Review" (0-255) range. The assigned IDs are show in Table 7. 1851 +-------------------------+-----+ 1852 | Media type | ID | 1853 +-------------------------+-----+ 1854 | application/senml+json | TBD | 1855 | application/sensml+json | TBD | 1856 | application/senml+cbor | TBD | 1857 | application/sensml+cbor | TBD | 1858 | application/senml+xml | TBD | 1859 | application/sensml+xml | TBD | 1860 | application/senml+exi | TBD | 1861 | application/sensml+exi | TBD | 1862 +-------------------------+-----+ 1864 Table 7: CoAP Content-Format IDs 1866 13. Security Considerations 1868 See Section 14. Further discussion of security properties can be 1869 found in Section 12.3. 1871 14. Privacy Considerations 1873 Sensor data can range from information with almost no security 1874 considerations, such as the current temperature in a given city, to 1875 highly sensitive medical or location data. This specification 1876 provides no security protection for the data but is meant to be used 1877 inside another container or transport protocol such as S/MIME or HTTP 1878 with TLS that can provide integrity, confidentiality, and 1879 authentication information about the source of the data. 1881 15. Acknowledgement 1883 We would like to thank Alexander Pelov, Andrew McClure, Andrew 1884 Mcgregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, 1885 Daniel Peintner, Jan-Piet Mens, Joe Hildebrand, John Klensin, Karl 1886 Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Campbell, Martin 1887 Thomson, Michael Koster, and Stephen Farrell, for their review 1888 comments. 1890 16. References 1892 16.1. Normative References 1894 [BIPM] Bureau International des Poids et Mesures, "The 1895 International System of Units (SI)", 8th edition, 2006. 1897 [IEEE.754.1985] 1898 Institute of Electrical and Electronics Engineers, 1899 "Standard for Binary Floating-Point Arithmetic", IEEE 1900 Standard 754, August 1985. 1902 [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the 1903 International System of Units (SI)", NIST Special 1904 Publication 811, 2008. 1906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1907 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1908 RFC2119, March 1997, 1909 . 1911 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1912 DOI 10.17487/RFC3688, January 2004, 1913 . 1915 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1916 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1917 . 1919 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1920 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1921 DOI 10.17487/RFC5226, May 2008, 1922 . 1924 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1925 Specifications and Registration Procedures", BCP 13, RFC 1926 6838, DOI 10.17487/RFC6838, January 2013, 1927 . 1929 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1930 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1931 October 2013, . 1933 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1934 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1935 2014, . 1937 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1938 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 1939 RFC7252, June 2014, 1940 . 1942 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1943 DOI 10.17487/RFC7303, July 2014, 1944 . 1946 [W3C.REC-exi-20140211] 1947 Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, 1948 "Efficient XML Interchange (EXI) Format 1.0 (Second 1949 Edition)", World Wide Web Consortium Recommendation REC- 1950 exi-20140211, February 2014, 1951 . 1953 [W3C.REC-xml-20081126] 1954 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1955 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1956 Edition)", World Wide Web Consortium Recommendation REC- 1957 xml-20081126, November 2008, 1958 . 1960 16.2. Informative References 1962 [I-D.arkko-core-dev-urn] 1963 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource 1964 Names for Device Identifiers", draft-arkko-core-dev-urn-03 1965 (work in progress), July 2012. 1967 [I-D.greevenbosch-appsawg-cbor-cddl] 1968 Vigano, C. and H. Birkholz, "CBOR data definition language 1969 (CDDL): a notational convention to express CBOR data 1970 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 1971 in progress), September 2016. 1973 [I-D.ietf-core-links-json] 1974 Li, K., Rahman, A., and C. Bormann, "Representing CoRE 1975 Formats in JSON and CBOR", draft-ietf-core-links-json-06 1976 (work in progress), July 2016. 1978 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1979 May 1997, . 1981 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1982 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1983 3986, DOI 10.17487/RFC3986, January 2005, 1984 . 1986 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1987 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 1988 10.17487/RFC4122, July 2005, 1989 . 1991 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1992 Address Text Representation", RFC 5952, DOI 10.17487/ 1993 RFC5952, August 2010, 1994 . 1996 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1997 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1998 . 2000 [RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment 2001 Identifiers for the text/csv Media Type", RFC 7111, DOI 2002 10.17487/RFC7111, January 2014, 2003 . 2005 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2006 Considerations for IPv6 Address Generation Mechanisms", 2007 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2008 . 2010 [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units 2011 of Measure (UCUM)", Regenstrief Institute and Indiana 2012 University School of Informatics, 2013, 2013 . 2015 Appendix A. Links Extension 2017 An attribute to support a link extension for SenML is defined as a 2018 string attribute by this specification. The link extension can be 2019 used for additional information about a SenML Record. The definition 2020 and usage of the contents of this value are specified in 2021 [I-D.ietf-core-links-json]. 2023 For JSON and XML the attribute has a label of "l" and a value that is 2024 a string. 2026 The following shows an example of the links extension. 2028 [ 2029 {"bn":"urn:dev:ow:10e2073a01080063;","bt":1.320078429e+09, 2030 "l":"[{\"href\":\"humidity\",\"foo\":\"bar1\"}", 2031 "n":"temperature","u":"Cel","v":27.2}, 2032 {"n":"humidity","u":"%RH","v":80} 2033 ] 2035 Authors' Addresses 2037 Cullen Jennings 2038 Cisco 2039 400 3rd Avenue SW 2040 Calgary, AB T2P 4H2 2041 Canada 2043 Email: fluffy@iii.ca 2044 Zach Shelby 2045 ARM 2046 150 Rose Orchard 2047 San Jose 95134 2048 USA 2050 Phone: +1-408-203-9434 2051 Email: zach.shelby@arm.com 2053 Jari Arkko 2054 Ericsson 2055 Jorvas 02420 2056 Finland 2058 Email: jari.arkko@piuha.net 2060 Ari Keranen 2061 Ericsson 2062 Jorvas 02420 2063 Finland 2065 Email: ari.keranen@ericsson.com 2067 Carsten Bormann 2068 Universitaet Bremen TZI 2069 Postfach 330440 2070 Bremen D-28359 2071 Germany 2073 Phone: +49-421-218-63921 2074 Email: cabo@tzi.org