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