draft-ietf-core-senml-11.txt   draft-ietf-core-senml-12.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track Z. Shelby Intended status: Standards Track Z. Shelby
Expires: May 3, 2018 ARM Expires: June 17, 2018 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
October 30, 2017 December 14, 2017
Media Types for Sensor Measurement Lists (SenML) Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-11 draft-ietf-core-senml-12
Abstract Abstract
This specification defines media types for representing simple sensor This specification defines media types for representing simple sensor
measurements and device parameters in the Sensor Measurement Lists measurements and device parameters in the Sensor Measurement Lists
(SenML). Representations are defined in JavaScript Object Notation (SenML). Representations are defined in JavaScript Object Notation
(JSON), Concise Binary Object Representation (CBOR), eXtensible (JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model. A simple sensor, such as a share the common SenML data model. A simple sensor, such as a
temperature sensor, could use this media type in protocols such as temperature sensor, could use this media type in protocols such as
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on June 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6
4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 6 4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 6
4.3. Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Resolved Records . . . . . . . . . . . . . . . . . . . . 9 4.4. Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.5. Associating Meta-data . . . . . . . . . . . . . . . . . . 9 4.5. Resolved Records . . . . . . . . . . . . . . . . . . . . 10
4.6. Configuration and Actuation usage . . . . . . . . . . . . 10 4.6. Associating Meta-data . . . . . . . . . . . . . . . . . . 10
5. JSON Representation (application/senml+json) . . . . . . . . 10 4.7. Configuration and Actuation usage . . . . . . . . . . . . 10
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 5. JSON Representation (application/senml+json) . . . . . . . . 11
5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 11 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 11 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 12
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 12 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 12
5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 13
5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 14 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 14
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 14 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 15
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 15
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 15 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 15
6. CBOR Representation (application/senml+cbor) . . . . . . . . 16 6. CBOR Representation (application/senml+cbor) . . . . . . . . 16
7. XML Representation (application/senml+xml) . . . . . . . . . 18 7. XML Representation (application/senml+xml) . . . . . . . . . 18
8. EXI Representation (application/senml+exi) . . . . . . . . . 20 8. EXI Representation (application/senml+exi) . . . . . . . . . 20
9. Fragment Identification Methods . . . . . . . . . . . . . . . 23 9. Fragment Identification Methods . . . . . . . . . . . . . . . 23
9.1. Fragment Identification Examples . . . . . . . . . . . . 23 9.1. Fragment Identification Examples . . . . . . . . . . . . 23
10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24
11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26
12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 30 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 30
12.3. Media Type Registration . . . . . . . . . . . . . . . . 31 12.3. Media Type Registration . . . . . . . . . . . . . . . . 31
12.3.1. senml+json Media Type Registration . . . . . . . . . 31 12.3.1. senml+json Media Type Registration . . . . . . . . . 32
12.3.2. sensml+json Media Type Registration . . . . . . . . 33 12.3.2. sensml+json Media Type Registration . . . . . . . . 33
12.3.3. senml+cbor Media Type Registration . . . . . . . . . 34 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 34
12.3.4. sensml+cbor Media Type Registration . . . . . . . . 35 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 35
12.3.5. senml+xml Media Type Registration . . . . . . . . . 37 12.3.5. senml+xml Media Type Registration . . . . . . . . . 36
12.3.6. sensml+xml Media Type Registration . . . . . . . . . 38 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37
12.3.7. senml+exi Media Type Registration . . . . . . . . . 39 12.3.7. senml+exi Media Type Registration . . . . . . . . . 38
12.3.8. sensml+exi Media Type Registration . . . . . . . . . 41 12.3.8. sensml+exi Media Type Registration . . . . . . . . . 40
12.4. XML Namespace Registration . . . . . . . . . . . . . . . 42 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41
12.5. CoAP Content-Format Registration . . . . . . . . . . . . 42 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . 43 16.1. Normative References . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . 45 16.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Overview 1. Overview
Connecting sensors to the Internet is not new, and there have been Connecting sensors to the Internet is not new, and there have been
many protocols designed to facilitate it. This specification defines many protocols designed to facilitate it. This specification defines
new media types for carrying simple sensor information in a protocol new media types for carrying simple sensor information in a protocol
such as HTTP or CoAP. This format was designed so that processors such as HTTP or CoAP. This format was designed so that processors
with very limited capabilities could easily encode a sensor with very limited capabilities could easily encode a sensor
measurement into the media type, while at the same time a server measurement into the media type, while at the same time a server
parsing the data could relatively efficiently collect a large number parsing the data could relatively efficiently collect a large number
skipping to change at page 6, line 50 skipping to change at page 7, line 5
4.2. Regular Fields 4.2. Regular Fields
Name: Name of the sensor or parameter. When appended to the Base Name: Name of the sensor or parameter. When appended to the Base
Name field, this must result in a globally unique identifier for Name field, this must result in a globally unique identifier for
the resource. The name is optional, if the Base Name is present. the resource. The name is optional, if the Base Name is present.
If the name is missing, Base Name must uniquely identify the If the name is missing, Base Name must uniquely identify the
resource. This can be used to represent a large array of resource. This can be used to represent a large array of
measurements from the same sensor without having to repeat its measurements from the same sensor without having to repeat its
identifier on every measurement. identifier on every measurement.
Unit: Units for a measurement value. Optional. Unit: Unit for a measurement value. Optional.
Value: Value of the entry. Optional if a Sum value is present, Value: Value of the entry. Optional if a Sum value is present,
otherwise required. Values are represented using basic data otherwise required. Values are represented using basic data
types. This specification defines floating point numbers ("v" types. This specification defines floating point numbers ("v"
field for "Value"), booleans ("vb" for "Boolean Value"), strings field for "Value"), booleans ("vb" for "Boolean Value"), strings
("vs" for "String Value") and binary data ("vd" for "Data Value"). ("vs" for "String Value") and binary data ("vd" for "Data Value").
Exactly one value field MUST appear unless there is Sum field in Exactly one value field MUST appear unless there is Sum field in
which case it is allowed to have no Value field. which case it is allowed to have no Value field.
Sum: Integrated sum of the values over time. Optional. This field Sum: Integrated sum of the values over time. Optional. This field
is in the units specified in the Unit value multiplied by seconds. is in the unit specified in the Unit value multiplied by seconds.
Time: Time when value was recorded. Optional. Time: Time when value was recorded. Optional.
Update Time: Period of time in seconds that represents the maximum Update Time: Period of time in seconds that represents the maximum
time before this sensor will provide an updated reading for a time before this sensor will provide an updated reading for a
measurement. Optional. This can be used to detect the failure of measurement. Optional. This can be used to detect the failure of
sensors or communications path from the sensor. sensors or communications path from the sensor.
4.3. Considerations 4.3. SenML Labels
Table 1 provides an overview of all SenML fields defined by this
document with their respective labels and data types.
+---------------+-------+------------+------------+------------+
| Name | Label | CBOR Label | JSON Type | XML Type |
+---------------+-------+------------+------------+------------+
| Base Name | bn | -2 | String | string |
| Base Time | bt | -3 | Number | double |
| Base Unit | bu | -4 | String | string |
| Base Value | bv | -5 | Number | double |
| Base Sum | bs | -6 | Number | double |
| Version | bver | -1 | Number | int |
| Name | n | 0 | String | string |
| Unit | u | 1 | String | string |
| Value | v | 2 | Number | double |
| String Value | vs | 3 | String | string |
| Boolean Value | vb | 4 | Boolean | boolean |
| Data Value | vd | 8 | String (*) | string (*) |
| Value Sum | s | 5 | Number | double |
| Time | t | 6 | Number | double |
| Update Time | ut | 7 | Number | double |
+---------------+-------+------------+------------+------------+
Table 1: SenML Labels
Data Value is base64 encoded string with URL safe alphabet as defined
in Section 5 of [RFC4648], with padding omitted.
For details of the JSON representation see Section 5, for the CBOR
Section 6, and for the XML Section 7.
4.4. Considerations
The SenML format can be extended with further custom fields. Both The SenML format can be extended with further custom fields. Both
new base and regular fields are allowed. See Section 12.2 for new base and regular fields are allowed. See Section 12.2 for
details. Implementations MUST ignore fields they don't recognize details. Implementations MUST ignore fields they don't recognize
unless that field has a label name that ends with the '_' character unless that field has a label name that ends with the '_' character
in which case an error MUST be generated. in which case an error MUST be generated.
All SenML Records in a Pack MUST have the same version number. This All SenML Records in a Pack MUST have the same version number. This
is typically done by adding a Base Version field to only the first is typically done by adding a Base Version field to only the first
Record in the Pack. Record in the Pack.
skipping to change at page 9, line 13 skipping to change at page 10, line 5
of the measurement. of the measurement.
In summary, the structure of a SenML record is laid out to support a In summary, the structure of a SenML record is laid out to support a
single measurement per record. If multiple data values are measured single measurement per record. If multiple data values are measured
at the same time (e.g., air pressure and altitude), they are best at the same time (e.g., air pressure and altitude), they are best
kept as separate records linked through their Time value; this is kept as separate records linked through their Time value; this is
even true where one of the data values is more "meta" than others even true where one of the data values is more "meta" than others
(e.g., describes a condition that influences other measurements at (e.g., describes a condition that influences other measurements at
the same time). the same time).
4.4. Resolved Records 4.5. Resolved Records
Sometimes it is useful to be able to refer to a defined normalized Sometimes it is useful to be able to refer to a defined normalized
format for SenML records. This normalized format tends to get used format for SenML records. This normalized format tends to get used
for big data applications and intermediate forms when converting to for big data applications and intermediate forms when converting to
other formats. other formats.
A SenML Record is referred to as "resolved" if it does not contain A SenML Record is referred to as "resolved" if it does not contain
any base values, i.e., labels starting with the character 'b', except any base values, i.e., labels starting with the character 'b', except
for Version fields (see below), and has no relative times. To for Version fields (see below), and has no relative times. To
resolve the records, the base values of the SenML Pack (if any) are resolve the records, the base values of the SenML Pack (if any) are
skipping to change at page 9, line 37 skipping to change at page 10, line 29
addition the records need to be in chronological order. An example addition the records need to be in chronological order. An example
of this is show in Section 5.1.4. of this is show in Section 5.1.4.
The Version field MUST NOT be present in resolved records if the The Version field MUST NOT be present in resolved records if the
SenML version defined in this document is used and MUST be present SenML version defined in this document is used and MUST be present
otherwise in all the resolved SenML Records. otherwise in all the resolved SenML Records.
Future specification that defines new base fields need to specify how Future specification that defines new base fields need to specify how
the field is resolved. the field is resolved.
4.5. Associating Meta-data 4.6. Associating Meta-data
SenML is designed to carry the minimum dynamic information about SenML is designed to carry the minimum dynamic information about
measurements, and for efficiency reasons does not carry significant measurements, and for efficiency reasons does not carry significant
static meta-data about the device, object or sensors. Instead, it is static meta-data about the device, object or sensors. Instead, it is
assumed that this meta-data is carried out of band. For web assumed that this meta-data is carried out of band. For web
resources using SenML Packs, this meta-data can be made available resources using SenML Packs, this meta-data can be made available
using the CoRE Link Format [RFC6690]. The most obvious use of this using the CoRE Link Format [RFC6690]. The most obvious use of this
link format is to describe that a resource is available in a SenML link format is to describe that a resource is available in a SenML
format in the first place. The relevant media type indicator is format in the first place. The relevant media type indicator is
included in the Content-Type (ct=) link attribute (which is defined included in the Content-Type (ct=) link attribute (which is defined
for the Link Format in Section 7.2.1 of [RFC7252]). for the Link Format in Section 7.2.1 of [RFC7252]).
4.6. Configuration and Actuation usage 4.7. Configuration and Actuation usage
SenML can also be used for configuring parameters and controlling SenML can also be used for configuring parameters and controlling
actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP POST actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP POST
or PUT method) and the semantics of the target are such that SenML is or PUT method) and the semantics of the target are such that SenML is
interpreted as configuration/actuation, SenML Records are interpreted interpreted as configuration/actuation, SenML Records are interpreted
as a request to change the values of given (sub)resources (given as as a request to change the values of given (sub)resources (given as
names) to given values at the given time(s). The semantics of the names) to given values at the given time(s). The semantics of the
target resource supporting this usage can be described, e.g., using target resource supporting this usage can be described, e.g., using
[I-D.ietf-core-interfaces]. Examples of actuation usage are shown in [I-D.ietf-core-interfaces]. Examples of actuation usage are shown in
Section 5.1.7. Section 5.1.7.
5. JSON Representation (application/senml+json) 5. JSON Representation (application/senml+json)
For the SenML fields shown in Table 1, the SenML labels are used as For the SenML fields shown in Table 2, the SenML labels are used as
the JSON object member names within JSON objects representing the the JSON object member names within JSON objects representing the
JSON SenML Records. JSON SenML Records.
+---------------+-------+---------+ +---------------+-------+---------+
| Name | label | Type | | Name | label | Type |
+---------------+-------+---------+ +---------------+-------+---------+
| Base Name | bn | String | | Base Name | bn | String |
| Base Time | bt | Number | | Base Time | bt | Number |
| Base Unit | bu | String | | Base Unit | bu | String |
| Base Value | bv | Number | | Base Value | bv | Number |
skipping to change at page 10, line 43 skipping to change at page 11, line 31
| Unit | u | String | | Unit | u | String |
| Value | v | Number | | Value | v | Number |
| String Value | vs | String | | String Value | vs | String |
| Boolean Value | vb | Boolean | | Boolean Value | vb | Boolean |
| Data Value | vd | String | | Data Value | vd | String |
| Value Sum | s | Number | | Value Sum | s | Number |
| Time | t | Number | | Time | t | Number |
| Update Time | ut | Number | | Update Time | ut | Number |
+---------------+-------+---------+ +---------------+-------+---------+
Table 1: JSON SenML Labels Table 2: JSON SenML Labels
The root JSON value consists of an array with one JSON object for The root JSON value consists of an array with one JSON object for
each SenML Record. All the fields in the above table MAY occur in each SenML Record. All the fields in the above table MAY occur in
the records with member values of the type specified in the table. the records with member values of the type specified in the table.
Only the UTF-8 form of JSON is allowed. Characters in the String Only the UTF-8 form of JSON is allowed. Characters in the String
Value are encoded using the escape sequences defined in [RFC7159]. Value are encoded using the escape sequences defined in [RFC7159].
Octets in the Data Value are base64 encoded with URL safe alphabet as Octets in the Data Value are base64 encoded with URL safe alphabet as
defined in Section 5 of [RFC4648], with padding omitted. defined in Section 5 of [RFC4648], with padding omitted.
skipping to change at page 13, line 34 skipping to change at page 14, line 14
+----------+------+-----------------+ +----------+------+-----------------+
| Encoding | Size | Compressed Size | | Encoding | Size | Compressed Size |
+----------+------+-----------------+ +----------+------+-----------------+
| JSON | 573 | 206 | | JSON | 573 | 206 |
| XML | 649 | 235 | | XML | 649 | 235 |
| CBOR | 254 | 196 | | CBOR | 254 | 196 |
| EXI | 161 | 184 | | EXI | 161 | 184 |
+----------+------+-----------------+ +----------+------+-----------------+
Table 2: Size Comparisons Table 3: Size Comparisons
5.1.4. Resolved Data 5.1.4. Resolved Data
The following shows the example from the previous section show in The following shows the example from the previous section show in
resolved format. resolved format.
[ [
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,
"v":20}, "v":20},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09,
skipping to change at page 16, line 35 skipping to change at page 17, line 10
a representation SHOULD be chosen such that when the CBOR value is a representation SHOULD be chosen such that when the CBOR value is
converted back to an IEEE double precision floating point value, converted back to an IEEE double precision floating point value,
it has exactly the same value as the original Number. For the it has exactly the same value as the original Number. For the
version number, only an unsigned integer is allowed. version number, only an unsigned integer is allowed.
o Characters in the String Value are encoded using a definite length o Characters in the String Value are encoded using a definite length
text string (type 3). Octets in the Data Value are encoded using text string (type 3). Octets in the Data Value are encoded using
a definite length byte string (type 2). a definite length byte string (type 2).
o For compactness, the CBOR representation uses integers for the o For compactness, the CBOR representation uses integers for the
labels, as defined in Table 3. This table is conclusive, i.e., labels, as defined in Table 4. This table is conclusive, i.e.,
there is no intention to define any additional integer map keys; there is no intention to define any additional integer map keys;
any extensions will use string map keys. This allows translators any extensions will use string map keys. This allows translators
converting between CBOR and JSON representations to convert also converting between CBOR and JSON representations to convert also
all future labels without needing to update implementations. all future labels without needing to update implementations.
+---------------+-------+------------+ +---------------+-------+------------+
| Name | Label | CBOR Label | | Name | Label | CBOR Label |
+---------------+-------+------------+ +---------------+-------+------------+
| Version | bver | -1 | | Version | bver | -1 |
| Base Name | bn | -2 | | Base Name | bn | -2 |
| Base Time | bt | -3 | | Base Time | bt | -3 |
| Base Units | bu | -4 | | Base Unit | bu | -4 |
| Base Value | bv | -5 | | Base Value | bv | -5 |
| Base Sum | bs | -6 | | Base Sum | bs | -6 |
| Name | n | 0 | | Name | n | 0 |
| Units | u | 1 | | Unit | u | 1 |
| Value | v | 2 | | Value | v | 2 |
| String Value | vs | 3 | | String Value | vs | 3 |
| Boolean Value | vb | 4 | | Boolean Value | vb | 4 |
| Value Sum | s | 5 | | Value Sum | s | 5 |
| Time | t | 6 | | Time | t | 6 |
| Update Time | ut | 7 | | Update Time | ut | 7 |
| Data Value | vd | 8 | | Data Value | vd | 8 |
+---------------+-------+------------+ +---------------+-------+------------+
Table 3: CBOR representation: integers for map keys Table 4: CBOR representation: integers for map keys
o For streaming SensML in CBOR representation, the array containing o For streaming SensML in CBOR representation, the array containing
the records SHOULD be a CBOR indefinite length array while for the records SHOULD be a CBOR indefinite length array while for
non-streaming SenML, a definite length array MUST be used. non-streaming SenML, a definite length array MUST be used.
The following example shows a dump of the CBOR example for the same The following example shows a dump of the CBOR example for the same
sensor measurement as in Section 5.1.2. sensor measurement as in Section 5.1.2.
0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:| 0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:|
0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3a |10e2073a0108006:| 0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3a |10e2073a0108006:|
skipping to change at page 19, line 25 skipping to change at page 19, line 31
| Unit | u | string | | Unit | u | string |
| Value | v | double | | Value | v | double |
| String Value | vs | string | | String Value | vs | string |
| Data Value | vd | string | | Data Value | vd | string |
| Boolean Value | vb | boolean | | Boolean Value | vb | boolean |
| Value Sum | s | double | | Value Sum | s | double |
| Time | t | double | | Time | t | double |
| Update Time | ut | double | | Update Time | ut | double |
+---------------+-------+---------+ +---------------+-------+---------+
Table 4: XML SenML Labels Table 5: XML SenML Labels
The RelaxNG schema for the XML is: The RelaxNG schema for the XML is:
default namespace = "urn:ietf:params:xml:ns:senml" default namespace = "urn:ietf:params:xml:ns:senml"
namespace rng = "http://relaxng.org/ns/structure/1.0" namespace rng = "http://relaxng.org/ns/structure/1.0"
senml = element senml { senml = element senml {
attribute bn { xsd:string }?, attribute bn { xsd:string }?,
attribute bt { xsd:double }?, attribute bt { xsd:double }?,
attribute bv { xsd:double }?, attribute bv { xsd:double }?,
skipping to change at page 24, line 18 skipping to change at page 24, line 18
as well as the an integrated sum. For many types of measurements, as well as the an integrated sum. For many types of measurements,
the sum is more useful than the current value. For example, an the sum is more useful than the current value. For example, an
electrical meter that measures the energy a given computer uses will electrical meter that measures the energy a given computer uses will
typically want to measure the cumulative amount of energy used. This typically want to measure the cumulative amount of energy used. This
is less prone to error than reporting the power each second and is less prone to error than reporting the power each second and
trying to have something on the server side sum together all the trying to have something on the server side sum together all the
power measurements. If the network between the sensor and the meter power measurements. If the network between the sensor and the meter
goes down over some period of time, when it comes back up, the goes down over some period of time, when it comes back up, the
cumulative sum helps reflect what happened while the network was cumulative sum helps reflect what happened while the network was
down. A meter like this would typically report a measurement with down. A meter like this would typically report a measurement with
the units set to watts, but it would put the sum of energy used in the unit set to watts, but it would put the sum of energy used in the
the "s" field of the measurement. It might optionally include the "s" field of the measurement. It might optionally include the
current power in the "v" field. current power in the "v" field.
While the benefit of using the integrated sum is fairly clear for While the benefit of using the integrated sum is fairly clear for
measurements like power and energy, it is less obvious for something measurements like power and energy, it is less obvious for something
like temperature. Reporting the sum of the temperature makes it easy like temperature. Reporting the sum of the temperature makes it easy
to compute averages even when the individual temperature values are to compute averages even when the individual temperature values are
not reported frequently enough to compute accurate averages. not reported frequently enough to compute accurate averages.
Implementers are encouraged to report the cumulative sum as well as Implementers are encouraged to report the cumulative sum as well as
the raw value of a given sensor. the raw value of a given sensor.
skipping to change at page 25, line 24 skipping to change at page 25, line 24
? bt => numeric, ; Base Time ? bt => numeric, ; Base Time
? bu => tstr, ; Base Units ? bu => tstr, ; Base Units
? bv => numeric, ; Base Value ? bv => numeric, ; Base Value
? bs => numeric, ; Base Sum ? bs => numeric, ; Base Sum
? bver => uint, ; Base Version ? bver => uint, ; Base Version
? n => tstr, ; Name ? n => tstr, ; Name
? u => tstr, ; Units ? u => tstr, ; Units
? s => numeric, ; Value Sum ? s => numeric, ; Value Sum
? t => numeric, ; Time ? t => numeric, ; Time
? ut => numeric, ; Update Time ? ut => numeric, ; Update Time
? l => tstr, ; Link
? ( v => numeric // ; Numeric Value ? ( v => numeric // ; Numeric Value
vs => tstr // ; String Value vs => tstr // ; String Value
vb => bool // ; Boolean Value vb => bool // ; Boolean Value
vd => binary-value ) ; Data Value vd => binary-value ) ; Data Value
* key-value-pair * key-value-pair
} }
; now define the generic versions ; now define the generic versions
key-value-pair = ( label => value ) key-value-pair = ( label => value )
skipping to change at page 26, line 9 skipping to change at page 26, line 9
Figure 1: Common CDDL specification for CBOR and JSON SenML Figure 1: Common CDDL specification for CBOR and JSON SenML
For JSON, we use text labels and base64url-encoded binary data For JSON, we use text labels and base64url-encoded binary data
(Figure 2). (Figure 2).
bver = "bver" n = "n" s = "s" bver = "bver" n = "n" s = "s"
bn = "bn" u = "u" t = "t" bn = "bn" u = "u" t = "t"
bt = "bt" v = "v" ut = "ut" bt = "bt" v = "v" ut = "ut"
bu = "bu" vs = "vs" vd = "vd" bu = "bu" vs = "vs" vd = "vd"
bv = "bv" vb = "vb" l = "l" bv = "bv" vb = "vb"
bs = "bs" bs = "bs"
binary-value = tstr ; base64url encoded binary-value = tstr ; base64url encoded
Figure 2: JSON-specific CDDL specification for SenML Figure 2: JSON-specific CDDL specification for SenML
For CBOR, we use integer labels and native binary data (Figure 3). For CBOR, we use integer labels and native binary data (Figure 3).
bver = -1 n = 0 s = 5 bver = -1 n = 0 s = 5
bn = -2 u = 1 t = 6 bn = -2 u = 1 t = 6
bt = -3 v = 2 ut = 7 bt = -3 v = 2 ut = 7
bu = -4 vs = 3 vd = 8 bu = -4 vs = 3 vd = 8
bv = -5 vb = 4 l = 9 bv = -5 vb = 4
bs = -6 bs = -6
binary-value = bstr binary-value = bstr
Figure 3: CBOR-specific CDDL specification for SenML Figure 3: CBOR-specific CDDL specification for SenML
12. IANA Considerations 12. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with
the RFC number of this specification. the RFC number of this specification.
skipping to change at page 28, line 21 skipping to change at page 28, line 21
| | level) | | | | | level) | | |
| 1/s | 1 per second (event rate) | float | RFC-AAAA | | 1/s | 1 per second (event rate) | float | RFC-AAAA |
| 1/min | 1 per minute (event rate, "rpm")* | float | RFC-AAAA | | 1/min | 1 per minute (event rate, "rpm")* | float | RFC-AAAA |
| beat/min | 1 per minute (Heart rate in beats | float | RFC-AAAA | | beat/min | 1 per minute (Heart rate in beats | float | RFC-AAAA |
| | per minute)* | | | | | per minute)* | | |
| beats | 1 (Cumulative number of heart | float | RFC-AAAA | | beats | 1 (Cumulative number of heart | float | RFC-AAAA |
| | beats)* | | | | | beats)* | | |
| S/m | Siemens per meter (conductivity) | float | RFC-AAAA | | S/m | Siemens per meter (conductivity) | float | RFC-AAAA |
+----------+------------------------------------+-------+-----------+ +----------+------------------------------------+-------+-----------+
Table 5 Table 6
o Note 1: Assumed to be in WGS84 unless another reference frame is o Note 1: Assumed to be in WGS84 unless another reference frame is
known for the sensor. known for the sensor.
o Note 2: A value of 0.0 indicates the switch is off while 1.0 o Note 2: A value of 0.0 indicates the switch is off while 1.0
indicates on and 0.5 would be half on. The preferred name of this indicates on and 0.5 would be half on. The preferred name of this
unit is "/". For historical reasons, the name "%" is also unit is "/". For historical reasons, the name "%" is also
provided for the same unit - but note that while that name provided for the same unit - but note that while that name
strongly suggests a percentage (0..100) -- it is however NOT a strongly suggests a percentage (0..100) -- it is however NOT a
percentage, but the absolute ratio! percentage, but the absolute ratio!
New entries can be added to the registration by Expert Review as New entries can be added to the registration by Expert Review as
defined in [RFC8126]. Experts should exercise their own good defined in [RFC8126]. Experts should exercise their own good
judgment but need to consider the following guidelines: judgment but need to consider the following guidelines:
1. There needs to be a real and compelling use for any new unit to 1. There needs to be a real and compelling use for any new unit to
be added. be added.
2. Units should define the semantic information and be chosen 2. Each unit should define the semantic information and be chosen
carefully. implementers need to remember that the same word may carefully. Implementers need to remember that the same word may
be used in different real-life contexts. For example, degrees be used in different real-life contexts. For example, degrees
when measuring latitude have no semantic relation to degrees when measuring latitude have no semantic relation to degrees
when measuring temperature; thus two different units are needed. when measuring temperature; thus two different units are needed.
3. These measurements are produced by computers for consumption by 3. These measurements are produced by computers for consumption by
computers. The principle is that conversion has to be easily be computers. The principle is that conversion has to be easily be
done when both reading and writing the media type. The value of done when both reading and writing the media type. The value of
a single canonical representation outweighs the convenience of a single canonical representation outweighs the convenience of
easy human representations or loss of precision in a conversion. easy human representations or loss of precision in a conversion.
skipping to change at page 30, line 13 skipping to change at page 30, line 13
name. name.
11. A good list of common units can be found in the Unified Code for 11. A good list of common units can be found in the Unified Code for
Units of Measure [UCUM]. Units of Measure [UCUM].
12.2. SenML Label Registry 12.2. SenML Label Registry
IANA will create a new registry for SenML labels. The initial IANA will create a new registry for SenML labels. The initial
content of the registry is: content of the registry is:
+---------------+-------+------+---------+--------+---------+ +--------------+-------+----+-----------+----------+----+-----------+
| Name | Label | CBOR | Type | EXI ID | Note | | Name | Label | CL | JSON Type | XML Type | EI | Reference |
+---------------+-------+------+---------+--------+---------+ +--------------+-------+----+-----------+----------+----+-----------+
| Base Name | bn | -2 | string | a | RFCXXXX | | Base Name | bn | -2 | String | string | a | RFCXXXX |
| Base Sum | bs | -6 | double | a | RFCXXXX | | Base Time | bt | -3 | Number | double | a | RFCXXXX |
| Base Time | bt | -3 | double | a | RFCXXXX | | Base Unit | bu | -4 | String | string | a | RFCXXXX |
| Base Unit | bu | -4 | string | a | RFCXXXX | | Base Value | bv | -5 | Number | double | a | RFCXXXX |
| Base Value | bv | -5 | double | a | RFCXXXX | | Base Sum | bs | -6 | Number | double | a | RFCXXXX |
| Base Version | bver | -1 | int | a | RFCXXXX | | Base Version | bver | -1 | Number | int | a | RFCXXXX |
| Boolean Value | vb | 4 | boolean | a | RFCXXXX | | Name | n | 0 | String | string | a | RFCXXXX |
| Data Value | vd | 8 | string | a | RFCXXXX | | Unit | u | 1 | String | string | a | RFCXXXX |
| Name | n | 0 | string | a | RFCXXXX | | Value | v | 2 | Number | double | a | RFCXXXX |
| String Value | vs | 3 | string | a | RFCXXXX | | String Value | vs | 3 | String | string | a | RFCXXXX |
| Time | t | 6 | double | a | RFCXXXX | | Boolean | vb | 4 | Boolean | boolean | a | RFCXXXX |
| Unit | u | 1 | string | a | RFCXXXX | | Value | | | | | | |
| Update Time | ut | 7 | double | a | RFCXXXX | | Data Value | vd | 8 | String | string | a | RFCXXXX |
| Value | v | 2 | double | a | RFCXXXX | | Value Sum | s | 5 | Number | double | a | RFCXXXX |
| Value Sum | s | 5 | double | a | RFCXXXX | | Time | t | 6 | Number | double | a | RFCXXXX |
+---------------+-------+------+---------+--------+---------+ | Update Time | ut | 7 | Number | double | a | RFCXXXX |
+--------------+-------+----+-----------+----------+----+-----------+
Table 6: SenML Labels Table 7: IANA Registry for SenML Labels, CL = CBOR Label, EI = EXI ID
This is the same table as Table 1, with notes removed, and with
columns added for the information that is all the same for this
initial set of registrations, but will need to be supplied with a
different value for new registrations.
Note to RFC Editor. Please replace RFCXXXX with the number for this Note to RFC Editor. Please replace RFCXXXX with the number for this
RFC. RFC.
All new entries must define the Label Name, Label, and XML Type but All new entries must define the Label Name, Label, and XML Type but
the CBOR labels SHOULD be left empty as CBOR will use the string the CBOR labels SHOULD be left empty as CBOR will use the string
encoding for any new labels. The EXI ID column contains the EXI encoding for any new labels. The EI column contains the EXI schemaId
schemaId value of the first Schema which includes this label or is value of the first Schema which includes this label or is empty if
empty if this label was not intended for use with EXI. The Note this label was not intended for use with EXI. The Note field SHOULD
field SHOULD contain information about where to find out more contain information about where to find out more information about
information about this label. this label.
The JSON, CBOR, and EXI types are derived from the XML type. All XML The JSON, CBOR, and EXI types are derived from the XML type. All XML
numeric types such as double, float, integer and int become a JSON numeric types such as double, float, integer and int become a JSON
Number. XML boolean and string become a JSON Boolean and String Number. XML boolean and string become a JSON Boolean and String
respectively. CBOR represents numeric values with a CBOR type that respectively. CBOR represents numeric values with a CBOR type that
does not lose any information from the JSON value. EXI uses the XML does not lose any information from the JSON value. EXI uses the XML
types. types.
New entries can be added to the registration by either Expert Review New entries can be added to the registration by Expert Review as
or IESG Approval as defined in [RFC8126]. Experts should exercise defined in [RFC8126]. Experts should exercise their own good
their own good judgment but need to consider that shorter labels judgment but need to consider that shorter labels should have more
should have more strict review. New entries should not be made that strict review. New entries should not be made that counteract the
counteract the advice at the end of Section 4.3. advice at the end of Section 4.4.
All new SenML labels that have "base" semantics (see Section 4.1) All new SenML labels that have "base" semantics (see Section 4.1)
MUST start with the character 'b'. Regular labels MUST NOT start MUST start with the character 'b'. Regular labels MUST NOT start
with that character. with that character.
Extensions that add a label that is intended for use with XML need to Extensions that add a label that is intended for use with XML need to
create a new RelaxNG scheme that includes all the labels in the IANA create a new RelaxNG scheme that includes all the labels in the IANA
registry. registry.
Extensions that add a label that is intended for use with EXI need to Extensions that add a label that is intended for use with EXI need to
skipping to change at page 31, line 40 skipping to change at page 31, line 47
12.3. Media Type Registration 12.3. Media Type Registration
The following registrations are done following the procedure The following registrations are done following the procedure
specified in [RFC6838] and [RFC7303]. Clipboard formats are defined specified in [RFC6838] and [RFC7303]. Clipboard formats are defined
for the JSON and XML form of lists but do not make sense for streams for the JSON and XML form of lists but do not make sense for streams
or other formats. or other formats.
Note to RFC Editor - please remove this paragraph. Note that a Note to RFC Editor - please remove this paragraph. Note that a
request for media type review for senml+json was sent to the media- request for media type review for senml+json was sent to the media-
types@iana.org on Sept 21, 2010. A second request for all the types types@iana.org on Sept 21, 2010. A second request for all the types
was sent on October 31, 2016. was sent on October 31, 2016. Please change all instances of RFC-
AAAA with the RFC number of this document.
12.3.1. senml+json Media Type Registration 12.3.1. senml+json Media Type Registration
Type name: application Type name: application
Subtype name: senml+json Subtype name: senml+json
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
skipping to change at page 32, line 4 skipping to change at page 32, line 14
12.3.1. senml+json Media Type Registration 12.3.1. senml+json Media Type Registration
Type name: application Type name: application
Subtype name: senml+json Subtype name: senml+json
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using a subset of the Encoding considerations: Must be encoded as using a subset of the
encoding allowed in [RFC7159]. See RFC-AAAA for details. This encoding allowed in [RFC7159]. See RFC-AAAA for details. This
simplifies implementation of very simple system and does not impose simplifies implementation of very simple system and does not impose
any significant limitations as all this data is meant for machine to any significant limitations as all this data is meant for machine to
machine communications and is not meant to be human readable. machine communications and is not meant to be human readable.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any JSON Interoperability considerations: Applications should ignore any JSON
key value pairs that they do not understand. This allows backwards key value pairs that they do not understand. This allows backwards
compatibility extensions to this specification. The "bver" field can compatibility extensions to this specification. The "bver" field can
be used to ensure the receiver supports a minimal level of be used to ensure the receiver supports a minimal level of
functionality needed by the creator of the JSON object. functionality needed by the creator of the JSON object.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used by systems Applications that use this media type: The type is used by systems
skipping to change at page 33, line 28 skipping to change at page 33, line 31
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using a subset of the Encoding considerations: Must be encoded as using a subset of the
encoding allowed in [RFC7159]. See RFC-AAAA for details. This encoding allowed in [RFC7159]. See RFC-AAAA for details. This
simplifies implementation of very simple system and does not impose simplifies implementation of very simple system and does not impose
any significant limitations as all this data is meant for machine to any significant limitations as all this data is meant for machine to
machine communications and is not meant to be human readable. machine communications and is not meant to be human readable.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any JSON Interoperability considerations: Applications should ignore any JSON
key value pairs that they do not understand. This allows backwards key value pairs that they do not understand. This allows backwards
compatibility extensions to this specification. The "bver" field can compatibility extensions to this specification. The "bver" field can
be used to ensure the receiver supports a minimal level of be used to ensure the receiver supports a minimal level of
functionality needed by the creator of the JSON object. functionality needed by the creator of the JSON object.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used by systems Applications that use this media type: The type is used by systems
skipping to change at page 34, line 41 skipping to change at page 34, line 35
Subtype name: senml+cbor Subtype name: senml+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using [RFC7049]. See Encoding considerations: Must be encoded as using [RFC7049]. See
RFC-AAAA for details. RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any key Interoperability considerations: Applications should ignore any key
value pairs that they do not understand. This allows backwards value pairs that they do not understand. This allows backwards
compatibility extensions to this specification. The "bver" field can compatibility extensions to this specification. The "bver" field can
be used to ensure the receiver supports a minimal level of be used to ensure the receiver supports a minimal level of
functionality needed by the creator of the CBOR object. functionality needed by the creator of the CBOR object.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used by systems Applications that use this media type: The type is used by systems
skipping to change at page 36, line 4 skipping to change at page 35, line 36
12.3.4. sensml+cbor Media Type Registration 12.3.4. sensml+cbor Media Type Registration
Type name: application Type name: application
Subtype name: sensml+cbor Subtype name: sensml+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using [RFC7049]. See Encoding considerations: Must be encoded as using [RFC7049]. See
RFC-AAAA for details. RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any key Interoperability considerations: Applications should ignore any key
value pairs that they do not understand. This allows backwards value pairs that they do not understand. This allows backwards
compatibility extensions to this specification. The "bver" field can compatibility extensions to this specification. The "bver" field can
be used to ensure the receiver supports a minimal level of be used to ensure the receiver supports a minimal level of
functionality needed by the creator of the CBOR object. functionality needed by the creator of the CBOR object.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used by systems Applications that use this media type: The type is used by systems
skipping to change at page 37, line 18 skipping to change at page 36, line 43
Subtype name: senml+xml Subtype name: senml+xml
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using Encoding considerations: Must be encoded as using
[W3C.REC-xml-20081126]. See RFC-AAAA for details. [W3C.REC-xml-20081126]. See RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications should ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand. This allows
backwards compatibility extensions to this specification. The "bver" backwards compatibility extensions to this specification. The "bver"
attribute in the senml XML tag can be used to ensure the receiver attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of supports a minimal level of functionality needed by the creator of
the XML. the XML.
Published specification: RFC-AAAA Published specification: RFC-AAAA
skipping to change at page 38, line 33 skipping to change at page 38, line 5
Subtype name: sensml+xml Subtype name: sensml+xml
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using Encoding considerations: Must be encoded as using
[W3C.REC-xml-20081126]. See RFC-AAAA for details. [W3C.REC-xml-20081126]. See RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications should ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand. This allows
backwards compatibility extensions to this specification. The "bver" backwards compatibility extensions to this specification. The "bver"
attribute in the senml XML tag can be used to ensure the receiver attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of supports a minimal level of functionality needed by the creator of
the XML. the XML.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used by systems Applications that use this media type: The type is used by systems
that report e.g., electrical power usage and environmental that report e.g., electrical power usage and environmental
information such as temperature and humidity. It can be used for a information such as temperature and humidity. It can be used for a
wide range of sensor reporting systems. wide range of sensor reporting systems.
Fragment identifier considerations: Fragment identification for Fragment identifier considerations: Fragment identification for
application/senml+xml is supported by using fragment identifiers as application/senml+xml is supported by using fragment identifiers as
specified by RFC-AAAA. specified by RFC-AAAA.
Additional information: Additional information:
skipping to change at page 39, line 41 skipping to change at page 39, line 4
12.3.7. senml+exi Media Type Registration 12.3.7. senml+exi Media Type Registration
Type name: application Type name: application
Subtype name: senml+exi Subtype name: senml+exi
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using Encoding considerations: Must be encoded as using
[W3C.REC-exi-20140211]. See RFC-AAAA for details. [W3C.REC-exi-20140211]. See RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications should ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand. This allows
backwards compatibility extensions to this specification. The "bver" backwards compatibility extensions to this specification. The "bver"
attribute in the senml XML tag can be used to ensure the receiver attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of supports a minimal level of functionality needed by the creator of
the XML. Further information on using schemas to guide the EXI can the XML. Further information on using schemas to guide the EXI can
be found in RFC-AAAA. be found in RFC-AAAA.
Published specification: RFC-AAAA Published specification: RFC-AAAA
skipping to change at page 41, line 18 skipping to change at page 40, line 18
Subtype name: sensml+exi Subtype name: sensml+exi
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using Encoding considerations: Must be encoded as using
[W3C.REC-exi-20140211]. See RFC-AAAA for details. [W3C.REC-exi-20140211]. See RFC-AAAA for details.
Security considerations: Sensor data can contain a wide range of Security considerations: See Section 13 of RFC-AAAA.
information ranging from information that is very public, such the
outside temperature in a given city, to very private information that
requires integrity and confidentiality protection, such as patient
health information. This format does not provide any security and
instead relies on the transport protocol that carries it to provide
security. Given applications need to look at the overall context of
how this media type will be used to decide if the security is
adequate.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications should ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand. This allows
backwards compatibility extensions to this specification. The "bver" backwards compatibility extensions to this specification. The "bver"
attribute in the senml XML tag can be used to ensure the receiver attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of supports a minimal level of functionality needed by the creator of
the XML. Further information on using schemas to guide the EXI can the XML. Further information on using schemas to guide the EXI can
be found in RFC-AAAA. be found in RFC-AAAA.
Published specification: RFC-AAAA Published specification: RFC-AAAA
skipping to change at page 42, line 33 skipping to change at page 41, line 24
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URIs are XML namespaces XML: N/A, the requested URIs are XML namespaces
12.5. CoAP Content-Format Registration 12.5. CoAP Content-Format Registration
IANA is requested to assign CoAP Content-Format IDs for the SenML IANA is requested to assign CoAP Content-Format IDs for the SenML
media types in the "CoAP Content-Formats" sub-registry, within the media types in the "CoAP Content-Formats" sub-registry, within the
"CoRE Parameters" registry [RFC7252]. All IDs are assigned from the "CoRE Parameters" registry [RFC7252]. All IDs are assigned from the
"Expert Review" (0-255) range. The assigned IDs are show in Table 7. "Expert Review" (0-255) range. The assigned IDs are show in Table 8.
+-------------------------+-----+ +-------------------------+-----+
| Media type | ID | | Media type | ID |
+-------------------------+-----+ +-------------------------+-----+
| application/senml+json | TBD | | application/senml+json | TBD |
| application/sensml+json | TBD | | application/sensml+json | TBD |
| application/senml+cbor | TBD | | application/senml+cbor | TBD |
| application/sensml+cbor | TBD | | application/sensml+cbor | TBD |
| application/senml+xml | TBD | | application/senml+xml | TBD |
| application/sensml+xml | TBD | | application/sensml+xml | TBD |
| application/senml+exi | TBD | | application/senml+exi | TBD |
| application/sensml+exi | TBD | | application/sensml+exi | TBD |
+-------------------------+-----+ +-------------------------+-----+
Table 7: CoAP Content-Format IDs Table 8: CoAP Content-Format IDs
13. Security Considerations 13. Security Considerations
See Section 14. Further discussion of security properties can be Sensor data can contain a wide range of information ranging from
found in Section 12.3. information that is very public, such as the outside temperature in a
given city, to very private information that requires integrity and
confidentiality protection, such as patient health information. The
SenML format does not provide any security and instead relies on the
protocol that carries it to provide security. Applications using
SenML need to look at the overall context of how this media type will
be used to decide if the security is adequate.
See also Section 14.
14. Privacy Considerations 14. Privacy Considerations
Sensor data can range from information with almost no security Sensor data can range from information with almost no security
considerations, such as the current temperature in a given city, to considerations, such as the current temperature in a given city, to
highly sensitive medical or location data. This specification highly sensitive medical or location data. This specification
provides no security protection for the data but is meant to be used provides no security protection for the data but is meant to be used
inside another container or transport protocol such as S/MIME or HTTP inside another container or transport protocol such as S/MIME or HTTP
with TLS that can provide integrity, confidentiality, and with TLS that can provide integrity, confidentiality, and
authentication information about the source of the data. authentication information about the source of the data.
 End of changes. 47 change blocks. 
160 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/