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