idnits 2.17.1
draft-jennings-senml-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 17, 2012) is 4273 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. 'IEEE.754.1985'
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)
** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159)
-- Possible downref: Non-RFC (?) normative reference: ref. 'UCUM'
== Outdated reference: A later version (-05) exists of
draft-arkko-core-dev-urn-01
== Outdated reference: A later version (-18) exists of
draft-ietf-core-coap-10
-- Obsolete informational reference (is this intentional?): RFC 2141
(Obsoleted by RFC 8141)
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Jennings
3 Internet-Draft Cisco
4 Intended status: Standards Track Z. Shelby
5 Expires: January 18, 2013 Sensinode
6 J. Arkko
7 Ericsson
8 July 17, 2012
10 Media Types for Sensor Markup Language (SENML)
11 draft-jennings-senml-09
13 Abstract
15 This specification defines media types for representing simple sensor
16 measurements and device parameters in the Sensor Markup Language
17 (SenML). Representations are defined in JavaScript Object Notation
18 (JSON), eXtensible Markup Language (XML) and Efficient XML
19 Interchange (EXI), which share the common SenML data model. A simple
20 sensor, such as a temperature sensor, could use this media type in
21 protocols such as HTTP or CoAP to transport the measurements of the
22 sensor or to be configured.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on January 18, 2013.
41 Copyright Notice
43 Copyright (c) 2012 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3
60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 5. Associating Meta-data . . . . . . . . . . . . . . . . . . . . 7
63 6. JSON Representation (application/senml+json) . . . . . . . . . 8
64 6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
65 6.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . . 9
66 6.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 9
67 6.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 10
68 6.1.4. Collection of Resources . . . . . . . . . . . . . . . 10
69 7. XML Representation (application/senml+xml) . . . . . . . . . . 11
70 8. EXI Representation (application/senml-exi) . . . . . . . . . . 12
71 9. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 14
72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
73 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 15
74 10.1.1. senml+json Media Type Registration . . . . . . . . . . 16
75 10.1.2. senml+xml Media Type Registration . . . . . . . . . . 17
76 10.1.3. senml-exi Media Type Registration . . . . . . . . . . 18
77 10.2. XML Namespace Registration . . . . . . . . . . . . . . . . 18
78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
79 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 19
80 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 19
83 14.2. Informative References . . . . . . . . . . . . . . . . . . 20
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
86 1. Overview
88 Connecting sensors to the internet is not new, and there have been
89 many protocols designed to facilitate it. This specification defines
90 new media types for carrying simple sensor information in a protocol
91 such as HTTP or CoAP[I-D.ietf-core-coap] called the Sensor Markup
92 Language (SenML). This format was designed so that processors with
93 very limited capabilities could easily encode a sensor measurement
94 into the media type, while at the same time a server parsing the data
95 could relatively efficiently collect a large number of sensor
96 measurements. There are many types of more complex measurements and
97 measurements that this media type would not be suitable for. A
98 decision was made not to carry most of the meta data about the sensor
99 in this media type to help reduce the size of the data and improve
100 efficiency in decoding. Instead meta-data about a sensor resource
101 can be described out-of-band using the CoRE Link Format
102 [I-D.ietf-core-link-format]. The markup language can be used for a
103 variety of data flow models, most notably data feeds pushed from a
104 sensor to a collector, and the web resource model where the sensor is
105 requested as a resource representation (GET /sensor/temperature).
107 SenML is defined by a data model for measurements and simple meta-
108 data about measurements and devices. The data is structured as a
109 single object (with attributes) that contains an array of entries.
110 Each entry is an object that has attributes such as a unique
111 identifier for the sensor, the time the measurement was made, and the
112 current value. Serializations for this data model are defined for
113 JSON [RFC4627], XML and Efficient XML Interchange (EXI)
114 [W3C.REC-exi-20110310].
116 For example, the following shows a measurement from a temperature
117 gauge encoded in the JSON syntax.
118 {"e":[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.5, "u":"Cel" }]}
120 In the example above, the array in the object has a single
121 measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a
122 temperature of 23.5 degrees Celsius.
124 2. Requirements and Design Goals
126 The design goal is to be able to send simple sensor measurements in
127 small packets on mesh networks from large numbers of constrained
128 devices. Keeping the total size under 80 bytes makes this easy to
129 use on a wireless mesh network. It is always difficult to define
130 what small code is, but there is a desire to be able to implement
131 this in roughly 1 KB of flash on a 8 bit microprocessor. Experience
132 with Google power meter and large scale deployments has indicated
133 that the solution needs to support allowing multiple measurements to
134 be batched into a single HTTP or CoAP request. This "batch" upload
135 capability allows the server side to efficiently support a large
136 number of devices. It also conveniently supports batch transfers
137 from proxies and storage devices, even in situations where the sensor
138 itself sends just a single data item at a time. The multiple
139 measurements could be from multiple related sensors or from the same
140 sensor but at different times.
142 3. Terminology
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146 document are to be interpreted as described in RFC 2119 [RFC2119].
148 4. Semantics
150 Each representation caries a single SenML object that represents a
151 set of measurements and/or parameters. This object contains several
152 optional attributes described below and a mandatory array of one or
153 more entries.
155 Base Name
157 This is a string that is prepended to the names found in the
158 entries. This attribute is optional.
160 Base Time
162 A base time that is added to the time found in an entry. This
163 attribute is optional.
165 Base Units
167 A base unit that is assumed for all entries, unless otherwise
168 indicated. The base unit SHOULD comply with the Unified Code for
169 Units of Measure [UCUM] in case sensitive form (c/s column). This
170 attribute is optional.
172 Version
174 Version number of media type format. This attribute is optional
175 positive integer and defaults to 1 if not present.
177 Measurement or Parameter Entries
179 Array of values for sensor measurements or other generic
180 parameters (such as configuration parameters). If present there
181 must be at least one entry in the array.
183 Each array entry contains several attributes, some of which are
184 optional and some of which are mandatory.
186 Name
188 Name of the sensor or parameter. When appended to the Base Name
189 attribute, this must result in a globally unique identifier for
190 the resource. The name is optional, if the Base Name is present.
191 If the name is missing Base Name must uniquely identify the
192 resource. This can be used to represent a large array of
193 measurements from the same sensor without having to repeat its
194 identifier on every measurement.
196 Units
198 Units for a measurement value. The unit SHOULD comply with the
199 Unified Code for Units of Measure [UCUM] in case sensitive form
200 (c/s column). Optional, if Base Unit is present or if not
201 required for a parameter.
203 Value
205 Value of the entry. Optional if a Sum value is present, otherwise
206 required. Values are represented using three basic data types,
207 Floating point numbers ("v" field for "Value"), Booleans ("bv" for
208 "Boolean Value") and Strings ("sv" for "String Value"). Exactly
209 one of these three fields MUST appear.
211 Sum
213 Integrated sum of the values over time. Optional. This attribute
214 is in the units specified in the Unit value multiplied by seconds.
216 Time
218 Time when value was recorded. Optional.
220 Update Time
222 Update time. A time in seconds that represents the maximum time
223 before this sensor will provide an updated reading for a
224 measurement. This can be used to detect the failure of sensors or
225 communications path from the sensor. Optional.
227 The SenML format can be extended with further custom attributes
228 placed in the base object, or in an entry. Extensions in the base
229 object pertain to all entries, whereas extensions in an entry object
230 only pertain to that.
232 Systems reading one of the objects MUST check for the Version
233 attribute. If this value is a version number larger than the version
234 which the system understands, the system SHOULD NOT use this object.
235 This allows the version number to indicate that the object contains
236 mandatory to understand attributes. New version numbers can only be
237 defined in RFC which updates this specification or it successors.
239 The Name value is concatenated to the Base Name value to get the name
240 of the sensor. The resulting name needs to uniquely identify and
241 differentiate the sensor from all others. If the object is a
242 representation resulting from the request of a URI [RFC3986], then in
243 the absence of the Base Name attribute, this URI is used as the
244 default value of Base Name. Thus in this case the Name field needs
245 to be unique for that URI, for example an index or subresource name
246 of sensors handled by the URI.
248 Alternatively, for objects not related to a URI, a unique name is
249 required. In any case, it is RECOMMENDED that the full names are
250 represented as URIs or URNs [RFC2141]. One way to create a unique
251 name is to include a EUI-48 or EUI-64 identifier (A MAC address) or
252 some other bit string that is guaranteed uniqueness (such as a 1-wire
253 address) that is assigned to the device. Some of the examples in
254 this draft use the device URN type as specified in
255 [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to
256 generate a unique name.
258 The resulting concatenated name MUST consist only of characters out
259 of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_"
260 and it MUST start with a character out of the set "A" to "Z", "a" to
261 "z", or "0" to "9". This restricted character set was chosen so that
262 these names can be directly used as in other types of URI including
263 segments of an HTTP path with no special encoding. [RFC5952]
264 contains advice on encoding an IPv6 address in a name.
266 If either the Base Time or Time value is missing, the missing
267 attribute is considered to have a value of zero. The Base Time and
268 Time values are added together to get the time of measurement. A
269 time of zero indicates that the sensor does not know the absolute
270 time and the measurement was made roughly "now". A negative value is
271 used to indicate seconds in the past from roughly "now". A positive
272 value is used to indicate the number of seconds, excluding leap
273 seconds, since the start of the year 1970 in UTC .
275 Representing the statistical characteristics of measurements can be
276 very complex. Future specification may add new attributes to provide
277 better information about the statistical properties of the
278 measurement.
280 5. Associating Meta-data
282 SenML is designed to carry the minimum dynamic information about
283 measurements, and for efficiency reasons does not carry more static
284 meta-data about the device, object or sensors. Instead, it is
285 assumed that this meta-data is carried out of band. For web
286 resources using SenML representations, this meta-data can be made
287 available using the CoRE Link Format [I-D.ietf-core-link-format].
289 The CoRE Link Format provides a simple way to describe Web Links, and
290 in particular allows a web server to describe resources it is
291 hosting. The list of links that a web server has available, can be
292 discovered by retrieving the /.well-known/core resource, which
293 returns the list of links in the CoRE Link Format. Each link may
294 contain attributes, for example title, resource type, interface
295 description and content-type.
297 The most obvious use of this link format is to describe that a
298 resource is available in a SenML format in the first place. The
299 relevant media type indicator is included in the Content-Type (ct=)
300 attribute.
302 Further semantics about a resource can be included in the Resource
303 Type and Interface Description attributes. The Resource Type (rt=)
304 attribute is meant to give a semantic meaning to that resource. For
305 example rt="outdoor-temperature" would indicate static semantic
306 meaning in addition to the unit information included in SenML. The
307 Interface Description (if=) attribute is used to describe the REST
308 interface of a resource, and may include e.g. a reference to a WADL
309 description [WADL].
311 6. JSON Representation (application/senml+json)
313 Root variables:
315 +---------------------------+------+--------+
316 | SenML | JSON | Type |
317 +---------------------------+------+--------+
318 | Base Name | bn | String |
319 | Base Time | bt | Number |
320 | Base Units | bu | Number |
321 | Version | ver | Number |
322 | Measurement or Parameters | e | Array |
323 +---------------------------+------+--------+
325 Measurement or Parameter Entries:
327 +---------------+------+----------------+
328 | SenML | JSON | Notes |
329 +---------------+------+----------------+
330 | Name | n | String |
331 | Units | u | String |
332 | Value | v | Floating point |
333 | String Value | sv | String |
334 | Boolean Value | bv | Boolean |
335 | Value Sum | s | Floating point |
336 | Time | t | Number |
337 | Update Time | ut | Number |
338 +---------------+------+----------------+
340 All of the data is UTF-8, but since this is for machine to machine
341 communications on constrained systems, only characters with code
342 points between U+0001 and U+007F are allowed which corresponds to the
343 ASCII[RFC0020] subset of UTF-8.
345 The root contents MUST consist of exactly one JSON object as
346 specified by [RFC4627]. This object MAY contain a "bn" attribute
347 with a value of type string. This object MAY contain a "bt"
348 attribute with a value of type number. The object MAY contain a "bu"
349 attribute with a value of type string. The object MAY contain a
350 "ver" attribute with a value of type number. The object MAY contain
351 other attribute value pairs, and the object MUST contain exactly one
352 "e" attribute with a value of type array. The array MUST have one or
353 more measurement or parameter objects.
355 Inside each measurement or parameter object the "n", "u", and "sv"
356 attributes are of type string, the "t" and "ut" attributes are of
357 type number, the "bv" attribute is of type boolean, and the "v" and
358 "s" attributes are of type floating point. All the attributes are
359 optional, but as specified in Section 4, one of the "v", "sv", or
360 "bv" attributes MUST appear unless the "s" attribute is also present.
361 The "v", and "sv", and "bv" attributes MUST NOT appear together.
363 Systems receiving measurements MUST be able to process the range of
364 floating point numbers that are representable as an IEEE double-
365 precision floating-point numbers [IEEE.754.1985]. The number of
366 significant digits in any measurement is not relevant, so a reading
367 of 1.1 has exactly the same semantic meaning as 1.10. If the value
368 has an exponent, the "e" MUST be in lower case. The mantissa SHOULD
369 be less than 19 characters long and the exponent SHOULD be less than
370 5 characters long. This allows time values to have better than micro
371 second precision over the next 100 years.
373 6.1. Examples
375 6.1.1. Single Datapoint
377 The following shows a temperature reading taken approximately "now"
378 by a 1-wire sensor device that was assigned the unique 1-wire address
379 of 10e2073a01080063:
381 {"e":[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.5 }]}
383 6.1.2. Multiple Datapoints
385 The following example shows voltage and current now, i.e., at an
386 unspecified time. The device has an EUI-64 MAC address of
387 0024befffe804ff1.
389 {"e":[
390 { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
391 { "n": "current", "t": 0, "u": "A", "v": 1.2 }],
392 "bn": "urn:dev:mac:0024befffe804ff1/"
393 }
395 The next example is similar to the above one, but shows current at
396 Tue Jun 8 18:01:16 UTC 2010 and at each second for the previous 5
397 seconds.
399 {"e":[
400 { "n": "voltage", "u": "V", "v": 120.1 },
401 { "n": "current", "t": -5, "v": 1.2 },
402 { "n": "current", "t": -4, "v": 1.30 },
403 { "n": "current", "t": -3, "v": 0.14e1 },
404 { "n": "current", "t": -2, "v": 1.5 },
405 { "n": "current", "t": -1, "v": 1.6 },
406 { "n": "current", "t": 0, "v": 1.7 }],
407 "bn": "urn:dev:mac:0024befffe804ff1/",
408 "bt": 1276020076,
409 "ver": 1,
410 "bu": "A"
411 }
413 6.1.3. Multiple Measurements
415 The following example shows humidity measurements from a mobile
416 device with an IPv6 address 2001:db8::1, starting at Mon Oct 31 13:
417 24:24 UTC 2011. The device also provide position data, which is
418 provided in the same measurement or parameter array as separate
419 entries. Note time is used to for correlating data that belongs
420 together, e.g., a measurement and a parameter associated with it.
421 Finally, the device also reports extra data about its battery status
422 at a separate time.
424 {"e":[
425 { "v": 20.0, "t": 0 },
426 { "sv": "E 24' 30.621", "n": "lon", "t": 0 },
427 { "sv": "N 60' 7.965", "n": "lat", "t": 0 },
428 { "v": 20.3, "t": 60 },
429 { "sv": "E 24' 30.622", "n": "lon", "t": 60 },
430 { "sv": "N 60' 7.965", "n": "lat", "t": 60 },
431 { "v": 20.7, "t": 120 },
432 { "sv": "E 24' 30.623", "n": "lon", "t": 120 },
433 { "sv": "N 60' 7.966", "n": "lat", "t": 120 },
434 { "v": 98.0, "u": "%EL", "t": 150 },
435 { "v": 21.2, "t": 180 },
436 { "sv": "E 24' 30.628", "n": "lon", "t": 180 },
437 { "sv": "N 60' 7.967", "n": "lat", "t": 180 }],
438 "bn": "http://[2001:db8::1]",
439 "bt": 1320067464,
440 "bu": "%"
441 }
443 6.1.4. Collection of Resources
445 The following example shows how to query one device that can provide
446 multiple measurements. The example assumes that a client has fetched
447 information from a device at 2001:db8::2 by performing a GET
448 operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011,
449 and has gotten two separate values as a result, a temperature and
450 humidity measurement.
452 {"e":[
453 { "n": "temperature", "v": 27.2, "u": "Cel" },
454 { "n": "humidity", "v": 80, "u": "%" }],
455 "bn": "http://[2001:db8::2]/",
456 "bt": 1320078429,
457 "ver": 1
458 }
460 7. XML Representation (application/senml+xml)
462 A SenML object can also be represented in XML format as defined in
463 this section. The following example shows an XML example for the
464 same sensor measurement as in Section 6.1.2.
466
467
472
474
476
478
480
482
484
486
488 The RelaxNG schema for the XML is:
490 default namespace = "urn:ietf:params:xml:ns:senml"
491 namespace rng = "http://relaxng.org/ns/structure/1.0"
493 e = element e {
494 attribute n { xsd:string }?,
495 attribute u { xsd:string }?,
496 attribute v { xsd:float }?,
497 attribute sv { xsd:string }?,
498 attribute bv { xsd:boolean }?,
499 attribute s { xsd:decimal }?,
500 attribute t { xsd:int }?,
501 attribute ut { xsd:int }?,
502 p*
503 }
505 senml =
506 element senml {
507 attribute bn { xsd:string }?,
508 attribute bt { xsd:int }?,
509 attribute bu { xsd:string }?,
510 attribute ver { xsd:int }?,
511 e*
512 }
514 start = senml
516 8. EXI Representation (application/senml-exi)
518 For efficient transmission of SenML over e.g. a constrained network,
519 Efficient XML Interchange (EXI) can be used. This encodes the XML
520 Schema structure of SenML into binary tags and values rather than
521 ASCII text. An EXI representation of SenML SHOULD be made using the
522 strict schema-mode of EXI. This mode however does not allow tag
523 extensions to the schema, and therefore any extensions will be lost
524 in the encoding. For uses where extensions need to be preserved in
525 EXI, the non-strict schema mode of EXI MAY be used.
527 The EXI header option MUST be included. An EXI schemaID options MUST
528 be set to the value of "a" indicating the scheme provided in this
529 specification. Future revisions to the schema can change this
530 schemaID to allow for backwards compatibility. When the data will be
531 transported over COAP or HTTP, an EXI Cookie SHOULD NOT be used as it
532 simply makes things larger as is redundant to information provided in
533 the Content-Type header.
535 The following XSD Schema is generated from the RelaxNG and used for
536 strict schema guided EXI processing.
538
539
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
569 The following shows a hexdump of the EXI produced from encoding the
570 following XML example. Note that while this example is similar to
571 the first example in Section 6.1.2 in JSON format.
573
574
576
577
578
580 Which compresses to the following displayed in hexdump:
582 00000000 a0 30 0d 85 01 d7 57 26 e3 a6 46 57 63 a6 f7 73
583 00000010 a3 13 06 53 23 03 73 36 13 03 13 03 83 03 03 63
584 00000020 36 21 2e cd ed 8e 8c 2c ec a8 00 00 d5 95 88 4c
585 00000030 02 08 4b 1b ab 93 93 2b 73 a2 00 00 34 14 19 00
586 00000040 c0
588 The above example used the bit packed form of EXI but it is also
589 possible to use a byte packed form of EXI which can makes it easier
590 for a simple sensor to produce valid EXI without really implementing
591 EXI. Consider the example of a temperature sensor that produces a
592 value in tenths of degrees Celsius over a range of 0.0 to 55.0. = It
593 would produce XML SenML file such as:
595
596
598
599
601 The compressed form, using the byte alignment option of EXI, for the
602 above XML is the following:
604 00000000 a00048806c200200 1d75726e3a646576 |..H.l ...urn:dev|
605 00000010 3a6f773a31306532 3037336130313038 |:ow:10e2073a0108|
606 00000020 3030363303010674 656d700306646567 |0063...temp..deg|
607 00000030 430100e701010001 02 |C........|
609 A small temperature sensor devices that only generates this one EXI
610 file does not really need an full EXI implementation. It can simple
611 hard code the output replacing the one wire device ID starting at
612 byte 0x14 and going to byte 0x23 with it's device ID , and replacing
613 the value "0xe7 0x01" at location 0x33 to 0x34 with the current
614 temperature. The EXI Specification[W3C.REC-exi-20110310] contains
615 the full information on how floating point numbers are represented,
616 but for the purpose of this sensor, the temperature can be converted
617 to an integer in tenths of degrees ( 231 in this example ). EXI
618 stores 7 bits of the integer in each byte with the top bit set to one
619 if there are further bytes. So the first bytes at location 0x33 is
620 set to low 7 bits of the integer temperature in tenths of degrees
621 plus 0x80. In this example 231 & 0x7F + 0x80 = 0xE7. The second
622 byte at location 0x34 is set to the integer temperature in tenths of
623 degrees right shifted 7 bits. In this example 231 >> 7 = 0x01.
625 9. Usage Considerations
627 The measurements support sending both the current value of a sensor
628 as well as the an integrated sum. For many types of measurements,
629 the sum is more useful than the current value. For example, an
630 electrical meter that measures the energy a given computer uses will
631 typically want to measure the cumulative amount of energy used. This
632 is less prone to error than reporting the power each second and
633 trying to have something on the server side sum together all the
634 power measurements. If the network between the sensor and the meter
635 goes down over some period of time, when it comes back up, the
636 cumulative sum helps reflect what happened while the network was
637 down. A meter like this would typically report a measurement with
638 the units set to watts, but it would put the sum of energy used in
639 the "s" attribute of the measurement. It might optionally include
640 the current power in the "v" attribute.
642 While the benefit of using the integrated sum is fairly clear for
643 measurements like power and energy, it is less obvious for something
644 like temperature. Reporting the sum of the temperature makes it easy
645 to compute averages even when the individual temperature values are
646 not reported frequently enough to compute accurate averages.
647 Implementors are encouraged to report the cumulative sum as well as
648 the raw value of a given sensor.
650 Applications that use the cumulative sum values need to understand
651 they are very loosely defined by this specification, and depending on
652 the particular sensor implementation may behave in unexpected ways.
653 Applications should be able to deal with the following issues:
655 1. Many sensors will allow the cumulative sums to "wrap" back to
656 zero after the value gets sufficiently large.
657 2. Some sensors will reset the cumulative sum back to zero when the
658 device is reset, loses power, or is replaced with a different
659 sensor.
660 3. Applications cannot make assumptions about when the device
661 started accumulating values into the sum.
663 Typically applications can make some assumptions about specific
664 sensors that will allow them to deal with these problems. A common
665 assumption is that for sensors whose measurement values are always
666 positive, the sum should never get smaller; so if the sum does get
667 smaller, the application will know that one of the situations listed
668 above has happened.
670 10. IANA Considerations
672 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA"
673 with the RFC number of this specification.
675 10.1. Media Type Registration
677 The following registrations are done following the procedure
678 specified in [RFC4288] and [RFC3023].
680 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA"
681 with the RFC number of this specification.
683 10.1.1. senml+json Media Type Registration
685 Type name: application
687 Subtype name: senml+json
689 Required parameters: none
691 Optional parameters: none
693 Encoding considerations: Must be encoded as using a subset of the
694 encoding allowed in [RFC4627]. Specifically, only the ASCII[RFC0020]
695 subset of the UTF-8 characters are allowed. This simplifies
696 implementation of very simple system and does not impose any
697 significant limitations as all this data is meant for machine to
698 machine communications and is not meant to be human readable.
700 Security considerations: Sensor data can contain a wide range of
701 information ranging from information that is very public, such the
702 outside temperature in a given city, to very private information that
703 requires integrity and confidentiality protection, such as patient
704 health information. This format does not provide any security and
705 instead relies on the transport protocol that carries it to provide
706 security. Given applications need to look at the overall context of
707 how this media type will be used to decide if the security is
708 adequate.
710 Interoperability considerations: Applications should ignore any JSON
711 key value pairs that they do not understand. This allows backwards
712 compatibility extensions to this specification. The "ver" field can
713 be used to ensure the receiver supports a minimal level of
714 functionality needed by the creator of the JSON object.
716 Published specification: RFC-AAAA
718 Applications that use this media type: The type is used by systems
719 that report electrical power usage and environmental information such
720 as temperature and humidity. It can be used for a wide range of
721 sensor reporting systems.
723 Additional information:
725 Magic number(s): none
727 File extension(s): senml
728 Macintosh file type code(s): none
730 Person & email address to contact for further information: Cullen
731 Jennings
733 Intended usage: COMMON
735 Restrictions on usage: None
737 Author: Cullen Jennings
739 Change controller: IESG
741 10.1.2. senml+xml Media Type Registration
743 Type name: application
745 Subtype name: senml+xml
747 Required parameters: none
749 Optional parameters: none
751 Encoding considerations: TBD
753 Security considerations: TBD
755 Interoperability considerations: TBD
757 Published specification: RFC-AAAA
759 Applications that use this media type: TBD
761 Additional information:
763 Magic number(s): none
765 File extension(s): senml
767 Macintosh file type code(s): none
769 Person & email address to contact for further information: Cullen
770 Jennings
772 Intended usage: COMMON
774 Restrictions on usage: None
775 Author: Cullen Jennings
777 Change controller: IESG
779 10.1.3. senml-exi Media Type Registration
781 Type name: application
783 Subtype name: senml-exi
785 Required parameters: none
787 Optional parameters: none
789 Encoding considerations: TBD
791 Security considerations: TBD
793 Interoperability considerations: TBD
795 Published specification: RFC-AAAA
797 Applications that use this media type: TBD
799 Additional information:
801 Magic number(s): none
803 File extension(s): senml
805 Macintosh file type code(s): none
807 Person & email address to contact for further information: Cullen
808 Jennings
810 Intended usage: COMMON
812 Restrictions on usage: None
814 Author: Cullen Jennings
816 Change controller: IESG
818 10.2. XML Namespace Registration
820 This document registers the following XML name paces in the IETF XML
821 registry defined in [RFC3688].
823 URI: urn:ietf:params:xml:ns:senml
825 Registrant Contact: The IESG.
827 XML: N/A, the requested URIs are XML namespaces
829 11. Security Considerations
831 See Section 12.Further discussion of security proprieties can be
832 found in Section 10.1.
834 12. Privacy Considerations
836 Sensor data can range from information with almost no security
837 considerations, such as the current temperature in a given city, to
838 highly sensitive medical or location data. This specification
839 provides no security protection for the data but is meant to be used
840 inside another container or transport protocol such as S/MIME or HTTP
841 with TLS that can provide integrity, confidentiality, and
842 authentication information about the source of the data.
844 13. Acknowledgement
846 We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay
847 Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, and Carsten
848 Bormann for their review comments.
850 14. References
852 14.1. Normative References
854 [IEEE.754.1985]
855 Institute of Electrical and Electronics Engineers,
856 "Standard for Binary Floating-Point Arithmetic",
857 IEEE Standard 754, August 1985.
859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
860 Requirement Levels", BCP 14, RFC 2119, March 1997.
862 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
863 Types", RFC 3023, January 2001.
865 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
866 January 2004.
868 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
869 Registration Procedures", BCP 13, RFC 4288, December 2005.
871 [RFC4627] Crockford, D., "The application/json Media Type for
872 JavaScript Object Notation (JSON)", RFC 4627, July 2006.
874 [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units
875 of Measure (UCUM)", Regenstrief Institute and Indiana
876 University School of Informatics .
878 [W3C.REC-exi-20110310]
879 Kamiya, T. and J. Schneider, "Efficient XML Interchange
880 (EXI) Format 1.0", World Wide Web Consortium
881 Recommendation REC-exi-20110310, March 2011,
882 .
884 14.2. Informative References
886 [I-D.arkko-core-dev-urn]
887 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
888 Names for Device Identifiers", draft-arkko-core-dev-urn-01
889 (work in progress), October 2011.
891 [I-D.ietf-core-coap]
892 Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
893 "Constrained Application Protocol (CoAP)",
894 draft-ietf-core-coap-10 (work in progress), October 2011.
896 [I-D.ietf-core-link-format]
897 Shelby, Z., "CoRE Link Format",
898 draft-ietf-core-link-format-14 (work in progress),
899 November 2011.
901 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
902 October 1969.
904 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
906 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
907 Resource Identifier (URI): Generic Syntax", STD 66,
908 RFC 3986, January 2005.
910 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
911 Unique IDentifier (UUID) URN Namespace", RFC 4122,
912 July 2005.
914 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
915 Address Text Representation", RFC 5952, August 2010.
917 [WADL] Hadley, M., "Web Application Description Language (WADL)",
918 2009, .
921 Authors' Addresses
923 Cullen Jennings
924 Cisco
925 170 West Tasman Drive
926 San Jose, CA 95134
927 USA
929 Phone: +1 408 421-9990
930 Email: fluffy@cisco.com
932 Zach Shelby
933 Sensinode
934 Kidekuja 2
935 Vuokatti 88600
936 FINLAND
938 Phone: +358407796297
939 Email: zach@sensinode.com
941 Jari Arkko
942 Ericsson
943 Jorvas 02420
944 Finland
946 Email: jari.arkko@piuha.net