draft-ietf-core-senml-12.txt   draft-ietf-core-senml-13.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: June 17, 2018 ARM Expires: September 3, 2018 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
December 14, 2017 March 02, 2018
Media Types for Sensor Measurement Lists (SenML) Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-12 draft-ietf-core-senml-13
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 one of these media types in protocols
HTTP or CoAP to transport the measurements of the sensor or to be such as HTTP or CoAP to transport the measurements of the sensor or
configured. to be configured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 17, 2018. This Internet-Draft will expire on September 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . 7
4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 7 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.4. Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.5. Resolved Records . . . . . . . . . . . . . . . . . . . . 10 4.5. Resolved Records . . . . . . . . . . . . . . . . . . . . 10
4.6. Associating Meta-data . . . . . . . . . . . . . . . . . . 10 4.6. Associating Meta-data . . . . . . . . . . . . . . . . . . 10
4.7. Configuration and Actuation usage . . . . . . . . . . . . 10 4.7. Configuration and Actuation usage . . . . . . . . . . . . 11
5. JSON Representation (application/senml+json) . . . . . . . . 11 5. JSON Representation (application/senml+json) . . . . . . . . 11
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 12 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 12
5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 12 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 12
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 13 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 13
5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 14 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 14
5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 15 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 15
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 15 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 15
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 15 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 16
6. CBOR Representation (application/senml+cbor) . . . . . . . . 16 6. CBOR Representation (application/senml+cbor) . . . . . . . . 17
7. XML Representation (application/senml+xml) . . . . . . . . . 18 7. XML Representation (application/senml+xml) . . . . . . . . . 19
8. EXI Representation (application/senml+exi) . . . . . . . . . 20 8. EXI Representation (application/senml-exi) . . . . . . . . . 21
9. Fragment Identification Methods . . . . . . . . . . . . . . . 23 9. Fragment Identification Methods . . . . . . . . . . . . . . . 24
9.1. Fragment Identification Examples . . . . . . . . . . . . 23 9.1. Fragment Identification Examples . . . . . . . . . . . . 24
10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 25
11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 27
12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 30 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 31
12.3. Media Type Registration . . . . . . . . . . . . . . . . 31 12.3. Media Type Registrations . . . . . . . . . . . . . . . . 32
12.3.1. senml+json Media Type Registration . . . . . . . . . 32 12.3.1. senml+json Media Type Registration . . . . . . . . . 33
12.3.2. sensml+json Media Type Registration . . . . . . . . 33 12.3.2. sensml+json Media Type Registration . . . . . . . . 34
12.3.3. senml+cbor Media Type Registration . . . . . . . . . 34 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 35
12.3.4. sensml+cbor Media Type Registration . . . . . . . . 35 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 36
12.3.5. senml+xml Media Type Registration . . . . . . . . . 36 12.3.5. senml+xml Media Type Registration . . . . . . . . . 37
12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 38
12.3.7. senml+exi Media Type Registration . . . . . . . . . 38 12.3.7. senml-exi Media Type Registration . . . . . . . . . 40
12.3.8. sensml+exi Media Type Registration . . . . . . . . . 40 12.3.8. sensml-exi Media Type Registration . . . . . . . . . 41
12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 42
12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 42
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 13. Security Considerations . . . . . . . . . . . . . . . . . . . 43
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Normative References . . . . . . . . . . . . . . . . . . 42 16.1. Normative References . . . . . . . . . . . . . . . . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . 44 16.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 [RFC7230] or CoAP [RFC7252]. This format was designed
with very limited capabilities could easily encode a sensor so that processors with very limited capabilities could easily encode
measurement into the media type, while at the same time a server a sensor measurement into the media type, while at the same time a
parsing the data could relatively efficiently collect a large number server parsing the data could relatively efficiently collect a large
of sensor measurements. SenML can be used for a variety of data flow number of sensor measurements. SenML can be used for a variety of
models, most notably data feeds pushed from a sensor to a collector, data flow models, most notably data feeds pushed from a sensor to a
and the web resource model where the sensor is requested as a collector, and the web resource model where the sensor is requested
resource representation (e.g., "GET /sensor/temperature"). as a resource representation (e.g., "GET /sensor/temperature").
There are many types of more complex measurements and measurements There are many types of more complex measurements and measurements
that this media type would not be suitable for. SenML strikes a that this media type would not be suitable for. SenML strikes a
balance between having some information about the sensor carried with balance between having some information about the sensor carried with
the sensor data so that the data is self describing but it also tries the sensor data so that the data is self describing but it also tries
to make that a fairly minimal set of auxiliary information for to make that a fairly minimal set of auxiliary information for
efficiency reason. Other information about the sensor can be efficiency reason. Other information about the sensor can be
discovered by other methods such as using the CoRE Link Format discovered by other methods such as using the CoRE Link Format
[RFC6690]. [RFC6690].
SenML is defined by a data model for measurements and simple meta- SenML is defined by a data model for measurements and simple meta-
data about measurements and devices. The data is structured as a data about measurements and devices. The data is structured as a
single array that contains a series of SenML Records which can each single array that contains a series of SenML Records which can each
contain fields such as an unique identifier for the sensor, the time contain fields such as an unique identifier for the sensor, the time
the measurement was made, the unit the measurement is in, and the the measurement was made, the unit the measurement is in, and the
current value of the sensor. Serializations for this data model are current value of the sensor. Serializations for this data model are
defined for JSON [RFC7159], CBOR [RFC7049], XML, and Efficient XML defined for JSON [RFC8259], CBOR [RFC7049], XML
Interchange (EXI) [W3C.REC-exi-20140211].
[W3C.REC-xml-20081126], and Efficient XML Interchange (EXI)
[W3C.REC-exi-20140211].
For example, the following shows a measurement from a temperature For example, the following shows a measurement from a temperature
gauge encoded in the JSON syntax. gauge encoded in the JSON syntax.
[ [
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
] ]
In the example above, the array has a single SenML Record with a In the example above, the array has a single SenML Record with a
measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a
skipping to change at page 5, line 19 skipping to change at page 5, line 19
"v":23.5}, "v":23.5},
{"u":"Cel","t":1.276020091e+09, {"u":"Cel","t":1.276020091e+09,
"v":23.6} "v":23.6}
] ]
In the above example the Base Name is in the "bn" field and the "n" In the above example the Base Name is in the "bn" field and the "n"
fields in each Record are the empty string so they are omitted. fields in each Record are the empty string so they are omitted.
Some devices have accurate time while others do not so SenML supports Some devices have accurate time while others do not so SenML supports
absolute and relative times. Time is represented in floating point absolute and relative times. Time is represented in floating point
as seconds and values greater than zero represent an absolute time as seconds. Values greater than zero represent an absolute time
relative to the Unix epoch while values of 0 or less represent a relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the
relative time in the past from the current time. A simple sensor time is counted same way as the Portable Operating System Interface
with no absolute wall clock time might take a measurement every (POSIX) "seconds since the epoch" [TIME_T]. Values of 0 or less
second, batch up 60 of them, and then send the batch to a server. It represent a relative time in the past from the current time. A
would include the relative time each measurement was made compared to simple sensor with no absolute wall clock time might take a
the time the batch was sent in each SenML Record. The server might measurement every second, batch up 60 of them, and then send the
have accurate NTP time and use the time it received the data, and the batch to a server. It would include the relative time each
relative offset, to replace the times in the SenML with absolute measurement was made compared to the time the batch was sent in each
times before saving the SenML Pack in a document database. SenML Record. The server might have accurate NTP time and use the
time it received the data, and the relative offset, to replace the
times in the SenML with absolute times before saving the SenML Pack
in a document database.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document also uses the following terms: This document also uses the following terms:
SenML Record: One measurement or configuration instance in time SenML Record: One measurement or configuration instance in time
presented using the SenML data model. presented using the SenML data model.
SenML Pack: One or more SenML Records in an array structure. SenML Pack: One or more SenML Records in an array structure.
SenML Label: A short name used in SenML Records to denote different SenML Label: A short name used in SenML Records to denote different
SenML fields (e.g., "v" for "value"). SenML fields (e.g., "v" for "value").
skipping to change at page 9, line 8 skipping to change at page 9, line 30
URIs [RFC3986] or URNs [RFC8141], the restricted character set URIs [RFC3986] or URNs [RFC8141], the restricted character set
specified above puts strict limits on the URI schemes and URN specified above puts strict limits on the URI schemes and URN
namespaces that can be used. As a result, implementers need to take namespaces that can be used. As a result, implementers need to take
care in choosing the naming scheme for concatenated names, because care in choosing the naming scheme for concatenated names, because
such names both need to be unique and need to conform to the such names both need to be unique and need to conform to the
restricted character set. One approach is to include a bit string restricted character set. One approach is to include a bit string
that has guaranteed uniqueness (such as a 1-wire address). Some of that has guaranteed uniqueness (such as a 1-wire address). Some of
the examples within this document use the device URN namespace as the examples within this document use the device URN namespace as
specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another
way to generate a unique name. However, the restricted character set way to generate a unique name. However, the restricted character set
does not allow the use of many URI schemes in names as such. The use does not allow the use of many URI schemes, such as the 'tag' scheme
[RFC4151] and the 'ni' scheme [RFC6920], in names as such. The use
of URIs with characters incompatible with this set, and possible of URIs with characters incompatible with this set, and possible
mapping rules between the two, are outside of the scope of the mapping rules between the two, are outside of the scope of the
present document. present document.
If the Record has no Unit, the Base Unit is used as the Unit. Having If the Record has no Unit, the Base Unit is used as the Unit. Having
no Unit and no Base Unit is allowed. no Unit and no Base Unit is allowed.
If either the Base Time or Time value is missing, the missing field If either the Base Time or Time value is missing, the missing field
is considered to have a value of zero. The Base Time and Time values is considered to have a value of zero. The Base Time and Time values
are added together to get the time of measurement. A time of zero are added together to get the time of measurement. A time of zero
skipping to change at page 11, line 37 skipping to change at page 12, line 9
| Time | t | Number | | Time | t | Number |
| Update Time | ut | Number | | Update Time | ut | Number |
+---------------+-------+---------+ +---------------+-------+---------+
Table 2: 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 [RFC3629] form of JSON is allowed. Characters in the
Value are encoded using the escape sequences defined in [RFC7159]. String Value are encoded using the escape sequences defined in
Octets in the Data Value are base64 encoded with URL safe alphabet as [RFC8259]. Octets in the Data Value are base64 encoded with URL safe
defined in Section 5 of [RFC4648], with padding omitted. alphabet as defined in Section 5 of [RFC4648], with padding omitted.
Systems receiving measurements MUST be able to process the range of Systems receiving measurements MUST be able to process the range of
floating point numbers that are representable as an IEEE double floating point numbers that are representable as an IEEE double
precision floating point numbers [IEEE.754.1985]. The number of precision floating point numbers [IEEE.754.1985]. This allows time
significant digits in any measurement is not relevant, so a reading values to have better than microsecond precision over the next 100
of 1.1 has exactly the same semantic meaning as 1.10. If the value years. The number of significant digits in any measurement is not
has an exponent, the "e" MUST be in lower case. The mantissa SHOULD relevant, so a reading of 1.1 has exactly the same semantic meaning
be less than 19 characters long and the exponent SHOULD be less than as 1.10. If the value has an exponent, the "e" MUST be in lower
5 characters long. This allows time values to have better than micro case. In the interest of avoiding unnecessary verbosity and speeding
second precision over the next 100 years. up processing, the mantissa SHOULD be less than 19 characters long
and the exponent SHOULD be less than 5 characters long.
5.1. Examples 5.1. Examples
5.1.1. Single Datapoint 5.1.1. Single Datapoint
The following shows a temperature reading taken approximately "now" The following shows a temperature reading taken approximately "now"
by a 1-wire sensor device that was assigned the unique 1-wire address by a 1-wire sensor device that was assigned the unique 1-wire address
of 10e2073a01080063: of 10e2073a01080063:
[ [
skipping to change at page 12, line 47 skipping to change at page 13, line 21
{"n":"current","t":-3,"v":1.4}, {"n":"current","t":-3,"v":1.4},
{"n":"current","t":-2,"v":1.5}, {"n":"current","t":-2,"v":1.5},
{"n":"current","t":-1,"v":1.6}, {"n":"current","t":-1,"v":1.6},
{"n":"current","v":1.7} {"n":"current","v":1.7}
] ]
Note that in some usage scenarios of SenML the implementations MAY Note that in some usage scenarios of SenML the implementations MAY
store or transmit SenML in a stream-like fashion, where data is store or transmit SenML in a stream-like fashion, where data is
collected over time and continuously added to the object. This mode collected over time and continuously added to the object. This mode
of operation is optional, but systems or protocols using SenML in of operation is optional, but systems or protocols using SenML in
this fashion MUST specify that they are doing this. SenML defines a this fashion MUST specify that they are doing this. SenML defines
separate media type to indicate Sensor Streaming Measurement Lists separate media types to indicate Sensor Streaming Measurement Lists
(SensML) for this usage (see Section 12.3.2). In this situation the (SensML) for this usage (see Section 12.3.2). In this situation the
SensML stream can be sent and received in a partial fashion, i.e., a SensML stream can be sent and received in a partial fashion, i.e., a
measurement entry can be read as soon as the SenML Record is received measurement entry can be read as soon as the SenML Record is received
and not have to wait for the full SensML Stream to be complete. and not have to wait for the full SensML Stream to be complete.
For instance, the following stream of measurements may be sent via a For instance, the following stream of measurements may be sent via a
long lived HTTP POST from the producer of a SensML to the consumer of long lived HTTP POST from the producer of a SensML to the consumer of
that, and each measurement object may be reported at the time it was that, and each measurement object may be reported at the time it was
measured: measured:
skipping to change at page 18, line 34 skipping to change at page 19, line 18
{0: "current", 6: -5, 2: 1.2}, {0: "current", 6: -4, 2: 1.3}, {0: "current", 6: -5, 2: 1.2}, {0: "current", 6: -4, 2: 1.3},
{0: "current", 6: -3, 2: 1.4}, {0: "current", 6: -2, 2: 1.5}, {0: "current", 6: -3, 2: 1.4}, {0: "current", 6: -2, 2: 1.5},
{0: "current", 6: -1, 2: 1.6}, {0: "current", 6: 0, 2: 1.7}] {0: "current", 6: -1, 2: 1.6}, {0: "current", 6: 0, 2: 1.7}]
7. XML Representation (application/senml+xml) 7. XML Representation (application/senml+xml)
A SenML Pack or Stream can also be represented in XML format as A SenML Pack or Stream can also be represented in XML format as
defined in this section. defined in this section.
Only the UTF-8 form of XML is allowed. Characters in the String Only the UTF-8 form of XML 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 [RFC8259].
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]. defined in Section 5 of [RFC4648].
The following example shows an XML example for the same sensor The following example shows an XML example for the same sensor
measurement as in Section 5.1.2. measurement as in Section 5.1.2.
<sensml xmlns="urn:ietf:params:xml:ns:senml"> <sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml bn="urn:dev:ow:10e2073a0108006:" bt="1.276020076001e+09" <senml bn="urn:dev:ow:10e2073a0108006:" bt="1.276020076001e+09"
bu="A" bver="5" n="voltage" u="V" v="120.1"></senml> bu="A" bver="5" n="voltage" u="V" v="120.1"></senml>
<senml n="current" t="-5" v="1.2"></senml> <senml n="current" t="-5" v="1.2"></senml>
skipping to change at page 19, line 33 skipping to change at page 20, line 27
| 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 5: XML SenML Labels Table 5: XML SenML Labels
The RelaxNG schema for the XML is: The RelaxNG [RNC] 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 }?,
attribute bs { xsd:double }?, attribute bs { xsd:double }?,
attribute bu { xsd:string }?, attribute bu { xsd:string }?,
skipping to change at page 20, line 35 skipping to change at page 21, line 35
attribute vd { xsd:string }? attribute vd { xsd:string }?
} }
sensml = sensml =
element sensml { element sensml {
senml+ senml+
} }
start = sensml start = sensml
8. EXI Representation (application/senml+exi) 8. EXI Representation (application/senml-exi)
For efficient transmission of SenML over e.g. a constrained network, For efficient transmission of SenML over e.g. a constrained network,
Efficient XML Interchange (EXI) can be used. This encodes the XML Efficient XML Interchange (EXI) can be used. This encodes the XML
Schema structure of SenML into binary tags and values rather than Schema [W3C.REC-xmlschema-1-20041028] structure of SenML into binary
ASCII text. An EXI representation of SenML SHOULD be made using the tags and values rather than ASCII text. An EXI representation of
strict schema-mode of EXI. This mode however does not allow tag SenML SHOULD be made using the strict schema-mode of EXI. This mode
extensions to the schema, and therefore any extensions will be lost however does not allow tag extensions to the schema, and therefore
in the encoding. For uses where extensions need to be preserved in any extensions will be lost in the encoding. For uses where
EXI, the non-strict schema mode of EXI MAY be used. extensions need to be preserved in EXI, the non-strict schema mode of
EXI MAY be used.
The EXI header MUST include an "EXI Options", as defined in The EXI header MUST include an "EXI Options", as defined in
[W3C.REC-exi-20140211], with an schemaId set to the value of "a" [W3C.REC-exi-20140211], with an schemaId set to the value of "a"
indicating the schema provided in this specification. Future indicating the schema provided in this specification. Future
revisions to the schema can change the value of the schemaId to allow revisions to the schema can change the value of the schemaId to allow
for backwards compatibility. When the data will be transported over for backwards compatibility. When the data will be transported over
CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes
things larger and is redundant to information provided in the things larger and is redundant to information provided in the
Content-Type header. Content-Type header.
skipping to change at page 25, line 7 skipping to change at page 26, line 7
Typically applications can make some assumptions about specific Typically applications can make some assumptions about specific
sensors that will allow them to deal with these problems. A common sensors that will allow them to deal with these problems. A common
assumption is that for sensors whose measurement values are always assumption is that for sensors whose measurement values are always
positive, the sum should never get smaller; so if the sum does get positive, the sum should never get smaller; so if the sum does get
smaller, the application will know that one of the situations listed smaller, the application will know that one of the situations listed
above has happened. above has happened.
11. CDDL 11. CDDL
For reference, the JSON and CBOR representations can be described As a convenient reference, the JSON and CBOR representations can be
with the common CDDL [I-D.ietf-cbor-cddl] specification in Figure 1. described with the common CDDL [I-D.ietf-cbor-cddl] specification in
Figure 1 (informative).
SenML-Pack = [1* record] SenML-Pack = [1* record]
record = { record = {
? bn => tstr, ; Base Name ? bn => tstr, ; Base Name
? 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
skipping to change at page 31, line 37 skipping to change at page 32, line 37
create a new XSD Schema that includes all the labels in the IANA create a new XSD Schema that includes all the labels in the IANA
registry and then allocate a new EXI schemaId value. Moving to the registry and then allocate a new EXI schemaId value. Moving to the
next letter in the alphabet is the suggested way to create the new next letter in the alphabet is the suggested way to create the new
value for the EXI schemaId. Any labels with previously blank ID value for the EXI schemaId. Any labels with previously blank ID
values SHOULD be updated in the IANA table to have their ID set to values SHOULD be updated in the IANA table to have their ID set to
this new schemaId value. this new schemaId value.
Extensions that are mandatory to understand to correctly process the Extensions that are mandatory to understand to correctly process the
Pack MUST have a label name that ends with the '_' character. Pack MUST have a label name that ends with the '_' character.
12.3. Media Type Registration 12.3. Media Type Registrations
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]. This document registers media
for the JSON and XML form of lists but do not make sense for streams types for each serialization format of SenML (JSON, CBOR, and EXI)
or other formats. and also media types for the same formats of the streaming use
(SensML). Clipboard formats are defined for the JSON and XML form of
lists but do not make sense for streams 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. Please change all instances of RFC- was sent on October 31, 2016. Please change all instances of RFC-
AAAA with the RFC number of this document. 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
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 [RFC8259]. 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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any JSON Interoperability considerations: Applications MUST ignore any JSON
key value pairs that they do not understand. This allows backwards key value pairs that they do not understand unless the key ends with
compatibility extensions to this specification. The "bver" field can the '_' character in which case an error MUST be generated. This
be used to ensure the receiver supports a minimal level of allows backwards compatible extensions to this specification. The
functionality needed by the creator of the JSON object. "bver" field can be used to ensure the receiver supports a minimal
level of 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
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+json is supported by using fragment identifiers as application/senml+json is supported by using fragment identifiers as
skipping to change at page 33, line 26 skipping to change at page 34, line 26
Type name: application Type name: application
Subtype name: sensml+json Subtype name: sensml+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 [RFC8259]. 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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any JSON Interoperability considerations: Applications MUST ignore any JSON
key value pairs that they do not understand. This allows backwards key value pairs that they do not understand unless the key ends with
compatibility extensions to this specification. The "bver" field can the '_' character in which case an error MUST be generated. This
be used to ensure the receiver supports a minimal level of allows backwards compatible extensions to this specification. The
functionality needed by the creator of the JSON object. "bver" field can be used to ensure the receiver supports a minimal
level of 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
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+json is supported by using fragment identifiers as application/senml+json is supported by using fragment identifiers as
skipping to change at page 34, line 37 skipping to change at page 35, line 37
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any key Interoperability considerations: Applications MUST ignore any key
value pairs that they do not understand. This allows backwards value pairs that they do not understand unless the key ends with the
compatibility extensions to this specification. The "bver" field can '_' character in which case an error MUST be generated. This allows
be used to ensure the receiver supports a minimal level of backwards compatible extensions to this specification. The "bver"
field can 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
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
skipping to change at page 35, line 42 skipping to change at page 36, line 46
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any key Interoperability considerations: Applications MUST ignore any key
value pairs that they do not understand. This allows backwards value pairs that they do not understand unless the key ends with the
compatibility extensions to this specification. The "bver" field can '_' character in which case an error MUST be generated. This allows
be used to ensure the receiver supports a minimal level of backwards compatible extensions to this specification. The "bver"
field can 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
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
skipping to change at page 36, line 45 skipping to change at page 37, line 50
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand unless the attribute
backwards compatibility extensions to this specification. The "bver" name ends with the '_' character in which case an error MUST be
attribute in the senml XML tag can be used to ensure the receiver generated. This allows backwards compatible extensions to this
supports a minimal level of functionality needed by the creator of specification. The "bver" attribute in the senml XML tag can be used
the XML. to ensure the receiver supports a minimal level of functionality
needed by the creator of the XML SenML Pack.
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
skipping to change at page 37, line 47 skipping to change at page 39, line 4
Change controller: IESG Change controller: IESG
12.3.6. sensml+xml Media Type Registration 12.3.6. sensml+xml Media Type Registration
Type name: application Type name: application
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand unless the attribute
backwards compatibility extensions to this specification. The "bver" name ends with the '_' character in which case an error MUST be
attribute in the senml XML tag can be used to ensure the receiver generated. This allows backwards compatible extensions to this
supports a minimal level of functionality needed by the creator of specification. The "bver" attribute in the senml XML tag can be used
the XML. to ensure the receiver supports a minimal level of functionality
needed by the creator of the XML SenML Pack.
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
skipping to change at page 38, line 44 skipping to change at page 40, line 5
Jennings <fluffy@iii.ca> Jennings <fluffy@iii.ca>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Cullen Jennings <fluffy@iii.ca> Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG Change controller: IESG
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand unless the attribute
backwards compatibility extensions to this specification. The "bver" name ends with the '_' character in which case an error MUST be
attribute in the senml XML tag can be used to ensure the receiver generated. This allows backwards compatible extensions to this
supports a minimal level of functionality needed by the creator of specification. The "bver" attribute in the senml XML tag can be used
the XML. Further information on using schemas to guide the EXI can to ensure the receiver supports a minimal level of functionality
be found in RFC-AAAA. needed by the creator of the XML SenML Pack. Further information on
using schemas to guide the EXI can be found in RFC-AAAA.
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+exi is supported by using fragment identifiers as application/senml-exi is supported by using fragment identifiers as
specified by RFC-AAAA. specified by RFC-AAAA.
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): senmle File extension(s): senmle
Macintosh file type code(s): none Macintosh file type code(s): none
skipping to change at page 39, line 41 skipping to change at page 41, line 4
File extension(s): senmle File extension(s): senmle
Macintosh file type code(s): none Macintosh file type code(s): none
Macintosh Universal Type Identifier code: org.ietf.senml-exi conforms Macintosh Universal Type Identifier code: org.ietf.senml-exi conforms
to public.data to public.data
Person & email address to contact for further information: Cullen Person & email address to contact for further information: Cullen
Jennings <fluffy@iii.ca> Jennings <fluffy@iii.ca>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Cullen Jennings <fluffy@iii.ca> Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG Change controller: IESG
12.3.8. sensml+exi Media Type Registration 12.3.8. sensml-exi Media Type Registration
Type name: application Type name: application
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: See Section 13 of RFC-AAAA. Security considerations: See Section 13 of RFC-AAAA.
Interoperability considerations: Applications should ignore any XML Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand. This allows tags or attributes that they do not understand unless the attribute
backwards compatibility extensions to this specification. The "bver" name ends with the '_' character in which case an error MUST be
attribute in the senml XML tag can be used to ensure the receiver generated. This allows backwards compatible extensions to this
supports a minimal level of functionality needed by the creator of specification. The "bver" attribute in the senml XML tag can be used
the XML. Further information on using schemas to guide the EXI can to ensure the receiver supports a minimal level of functionality
be found in RFC-AAAA. needed by the creator of the XML SenML Pack. Further information on
using schemas to guide the EXI can be found in RFC-AAAA.
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+exi is supported by using fragment identifiers as application/senml-exi is supported by using fragment identifiers as
specified by RFC-AAAA. specified by RFC-AAAA.
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): sensmle File extension(s): sensmle
Macintosh file type code(s): none Macintosh file type code(s): none
Person & email address to contact for further information: Cullen Person & email address to contact for further information: Cullen
Jennings <fluffy@iii.ca> Jennings <fluffy@iii.ca>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Cullen Jennings <fluffy@iii.ca> Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG Change controller: IESG
12.4. XML Namespace Registration 12.4. XML Namespace Registration
This document registers the following XML namespaces in the IETF XML This document registers the following XML namespaces in the IETF XML
registry defined in [RFC3688]. registry defined in [RFC3688].
URI: urn:ietf:params:xml:ns:senml URI: urn:ietf:params:xml:ns:senml
skipping to change at page 41, line 35 skipping to change at page 42, line 44
+-------------------------+-----+ +-------------------------+-----+
| 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 8: CoAP Content-Format IDs Table 8: CoAP Content-Format IDs
13. Security Considerations 13. Security Considerations
Sensor data can contain a wide range of information ranging from Sensor data can contain a wide range of information ranging from
information that is very public, such as the outside temperature in a information that is very public, such as the outside temperature in a
given city, to very private information that requires integrity and given city, to very private information that requires integrity and
confidentiality protection, such as patient health information. The confidentiality protection, such as patient health information. The
SenML format does not provide any security and instead relies on the SenML formats do not provide any security and instead rely on the
protocol that carries it to provide security. Applications using protocol that carries them to provide security. Applications using
SenML need to look at the overall context of how this media type will SenML need to look at the overall context of how these media types
be used to decide if the security is adequate. will be used to decide if the security is adequate. The SenML
formats defined by this specification do not contain any executable
content. However, future extensions could potentially embed
application specific executable content in the data.
See also Section 14. 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
with TLS that can provide integrity, confidentiality, and [RFC5751] or HTTP with TLS [RFC5246] that can provide integrity,
authentication information about the source of the data. confidentiality, and authentication information about the source of
the data.
The name fields need to uniquely identify the sources or destinations The name fields need to uniquely identify the sources or destinations
of the values in a SenML Pack. However, the use of long-term stable of the values in a SenML Pack. However, the use of long-term stable
unique identifiers can be problematic for privacy reasons [RFC6973], unique identifiers can be problematic for privacy reasons [RFC6973],
depending on the application and the potential of these identifiers depending on the application and the potential of these identifiers
to be used in correlation with other information. They should be to be used in correlation with other information. They should be
used with care or avoided as for example described for IPv6 addresses used with care or avoided as for example described for IPv6 addresses
in [RFC7721]. in [RFC7721].
15. Acknowledgement 15. Acknowledgement
We would like to thank Alexander Pelov, Andrew McClure, Andrew We would like to thank Alexander Pelov, Alexey Melnikov, Andrew
McGregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess,
Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe Hildebrand, John Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe
Klensin, Karl Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa
Campbell, Martin Thomson, Michael Koster, Peter Saint-Andre, and Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter
Stephen Farrell, for their review comments. Saint-Andre, and Stephen Farrell, for their review comments.
16. References 16. References
16.1. Normative References 16.1. Normative References
[BIPM] Bureau International des Poids et Mesures, "The [BIPM] Bureau International des Poids et Mesures, "The
International System of Units (SI)", 8th edition, 2006. International System of Units (SI)", 8th edition, 2006.
[IEEE.754.1985] [IEEE.754.1985]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
skipping to change at page 43, line 10 skipping to change at page 44, line 26
[NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the
International System of Units (SI)", NIST Special International System of Units (SI)", NIST Special
Publication 811, 2008. Publication 811, 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, <https://www.rfc-editor.org/info/ RFC2119, March 1997, <https://www.rfc-editor.org/info/
rfc2119>. rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, DOI 10.17487/RFC6838, January 2013, 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014, <https://www.rfc-editor.org/info/ RFC7252, June 2014, <https://www.rfc-editor.org/info/
rfc7252>. rfc7252>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, <https://www.rfc- DOI 10.17487/RFC7303, July 2014, <https://www.rfc-
editor.org/info/rfc7303>. editor.org/info/rfc7303>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, DOI 10.17487/
RFC8259, December 2017, <https://www.rfc-editor.org/info/
rfc8259>.
[RNC] ISO/IEC, "Information technology -- Document Schema
Definition Language (DSDL) -- Part 2: Regular-grammar-
based validation -- RELAX NG", ISO/IEC 19757-2, Annex C:
RELAX NG Compact syntax, December 2008.
[TIME_T] The Open Group Base Specifications, "Vol. 1: Base
Definitions, Issue 7", Section 4.15 'Seconds Since the
Epoch', IEEE Std 1003.1, 2013 Edition, 2013,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
V1_chap04.html#tag_04_15>.
[W3C.REC-exi-20140211] [W3C.REC-exi-20140211]
Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
"Efficient XML Interchange (EXI) Format 1.0 (Second "Efficient XML Interchange (EXI) Format 1.0 (Second
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
exi-20140211, February 2014, exi-20140211, February 2014,
<http://www.w3.org/TR/2014/REC-exi-20140211>. <http://www.w3.org/TR/2014/REC-exi-20140211>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
16.2. Informative References 16.2. Informative References
[I-D.arkko-core-dev-urn] [I-D.arkko-core-dev-urn]
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", draft-arkko-core-dev-urn-05 Names for Device Identifiers", draft-arkko-core-dev-urn-05
(work in progress), October 2017. (work in progress), October 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-00 express CBOR data structures", draft-ietf-cbor-cddl-02
(work in progress), July 2017. (work in progress), February 2018.
[I-D.ietf-core-interfaces] [I-D.ietf-core-interfaces]
Shelby, Z., Vial, M., Koster, M., Groves, C., Zhu, J., and Shelby, Z., Vial, M., Koster, M., Groves, C., Zhu, J., and
B. Silverajan, "Reusable Interface Definitions for B. Silverajan, "Reusable Interface Definitions for
Constrained RESTful Environments", draft-ietf-core- Constrained RESTful Environments", draft-ietf-core-
interfaces-10 (work in progress), September 2017. interfaces-10 (work in progress), September 2017.
[IEEE802.1as-2011] [IEEE802.1as-2011]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive Networks - Timing and Synchronization for Time-Sensitive
skipping to change at page 45, line 5 skipping to change at page 47, line 5
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI
10.17487/RFC4122, July 2005, <https://www.rfc- 10.17487/RFC4122, July 2005, <https://www.rfc-
editor.org/info/rfc4122>. editor.org/info/rfc4122>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008, <https://www.rfc-editor.org/info/
rfc5246>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/ Address Text Representation", RFC 5952, DOI 10.17487/
RFC5952, August 2010, <https://www.rfc-editor.org/info/ RFC5952, August 2010, <https://www.rfc-editor.org/info/
rfc5952>. rfc5952>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, DOI Considerations for Internet Protocols", RFC 6973, DOI
10.17487/RFC6973, July 2013, <https://www.rfc- 10.17487/RFC6973, July 2013, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment [RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment
Identifiers for the text/csv Media Type", RFC 7111, DOI Identifiers for the text/csv Media Type", RFC 7111, DOI
10.17487/RFC7111, January 2014, <https://www.rfc- 10.17487/RFC7111, January 2014, <https://www.rfc-
editor.org/info/rfc7111>. editor.org/info/rfc7111>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-
editor.org/info/rfc7230>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units
 End of changes. 58 change blocks. 
166 lines changed or deleted 240 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/