draft-ietf-core-senml-10.txt   draft-ietf-core-senml-11.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: January 4, 2018 ARM Expires: May 3, 2018 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
July 3, 2017 October 30, 2017
Media Types for Sensor Measurement Lists (SenML) Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-10 draft-ietf-core-senml-11
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 January 4, 2018. This Internet-Draft will expire on May 3, 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 29 skipping to change at page 2, line 29
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. Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.4. Resolved Records . . . . . . . . . . . . . . . . . . . . 8 4.4. Resolved Records . . . . . . . . . . . . . . . . . . . . 9
4.5. Associating Meta-data . . . . . . . . . . . . . . . . . . 9 4.5. Associating Meta-data . . . . . . . . . . . . . . . . . . 9
4.6. Configuration and Actuation usage . . . . . . . . . . . . 9 4.6. Configuration and Actuation usage . . . . . . . . . . . . 10
5. JSON Representation (application/senml+json) . . . . . . . . 9 5. JSON Representation (application/senml+json) . . . . . . . . 10
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 11 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 11
5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 11 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 11
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 12 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 12
5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 13 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 13
5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 14 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 14
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 14 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 14
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 14 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 15
6. CBOR Representation (application/senml+cbor) . . . . . . . . 15 6. CBOR Representation (application/senml+cbor) . . . . . . . . 16
7. XML Representation (application/senml+xml) . . . . . . . . . 17 7. XML Representation (application/senml+xml) . . . . . . . . . 18
8. EXI Representation (application/senml+exi) . . . . . . . . . 19 8. EXI Representation (application/senml+exi) . . . . . . . . . 20
9. Fragment Identification Methods . . . . . . . . . . . . . . . 22 9. Fragment Identification Methods . . . . . . . . . . . . . . . 23
9.1. Fragment Identification Examples . . . . . . . . . . . . 22 9.1. Fragment Identification Examples . . . . . . . . . . . . 23
10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 23 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24
11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 25 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26
12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 28 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 30
12.3. Media Type Registration . . . . . . . . . . . . . . . . 30 12.3. Media Type Registration . . . . . . . . . . . . . . . . 31
12.3.1. senml+json Media Type Registration . . . . . . . . . 30 12.3.1. senml+json Media Type Registration . . . . . . . . . 31
12.3.2. sensml+json Media Type Registration . . . . . . . . 32 12.3.2. sensml+json Media Type Registration . . . . . . . . 33
12.3.3. senml+cbor Media Type Registration . . . . . . . . . 33 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 34
12.3.4. sensml+cbor Media Type Registration . . . . . . . . 34 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 35
12.3.5. senml+xml Media Type Registration . . . . . . . . . 35 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 . . . . . . . . . 39
12.3.8. sensml+exi Media Type Registration . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 41 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
16.1. Normative References . . . . . . . . . . . . . . . . . . 42 16.1. Normative References . . . . . . . . . . . . . . . . . . 43
16.2. Informative References . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Links Extension . . . . . . . . . . . . . . . . . . 45 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 4, line 21 skipping to change at page 4, line 19
{"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
current value of 23.1 degrees Celsius. current value of 23.1 degrees Celsius.
2. Requirements and Design Goals 2. Requirements and Design Goals
The design goal is to be able to send simple sensor measurements in The design goal is to be able to send simple sensor measurements in
small packets on mesh networks from large numbers of constrained small packets from large numbers of constrained devices. Keeping the
devices. Keeping the total size of payload under 80 bytes makes this total size of payload small makes it easy to use SenML also in
easy to use on a wireless mesh network. It is always difficult to constrained networks, e.g., in a 6LoWPAN [RFC4944]. It is always
define what small code is, but there is a desire to be able to difficult to define what small code is, but there is a desire to be
implement this in roughly 1 KB of flash on a 8 bit microprocessor. able to implement this in roughly 1 KB of flash on a 8 bit
Experience with power meters and other large scale deployments has microprocessor. Experience with power meters and other large scale
indicated that the solution needs to support allowing multiple deployments has indicated that the solution needs to support allowing
measurements to be batched into a single HTTP or CoAP request. This multiple measurements to be batched into a single HTTP or CoAP
"batch" upload capability allows the server side to efficiently request. This "batch" upload capability allows the server side to
support a large number of devices. It also conveniently supports efficiently support a large number of devices. It also conveniently
batch transfers from proxies and storage devices, even in situations supports batch transfers from proxies and storage devices, even in
where the sensor itself sends just a single data item at a time. The situations where the sensor itself sends just a single data item at a
multiple measurements could be from multiple related sensors or from time. The multiple measurements could be from multiple related
the same sensor but at different times. sensors or from the same sensor but at different times.
The basic design is an array with a series of measurements. The The basic design is an array with a series of measurements. The
following example shows two measurements made at different times. following example shows two measurements made at different times.
The value of a measurement is given by the "v" field, the time of a The value of a measurement is given by the "v" field, the time of a
measurement is in the "t" field, the "n" field has a unique sensor measurement is in the "t" field, the "n" field has a unique sensor
name, and the unit of the measurement is carried in the "u" field. name, and the unit of the measurement is carried in the "u" field.
[ [
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09, {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
"v":23.5}, "v":23.5},
skipping to change at page 7, line 20 skipping to change at page 7, line 18
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 units specified in the Unit value multiplied by seconds.
Time: Time when value was recorded. Optional. Time: Time when value was recorded. Optional.
Update Time: An optional 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. This can be used to detect the failure of sensors or measurement. Optional. This can be used to detect the failure of
communications path from the sensor. sensors or communications path from the sensor.
4.3. Considerations 4.3. 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.
Systems reading one of the objects MUST check for the Version field. Systems reading one of the objects MUST check for the Version field.
If this value is a version number larger than the version which the If this value is a version number larger than the version which the
system understands, the system SHOULD NOT use this object. This system understands, the system SHOULD NOT use this object. This
allows the version number to indicate that the object contains allows the version number to indicate that the object contains
mandatory to understand fields. New version numbers can only be structure or semantics that is different from what is defined in the
defined in an RFC that updates this specification or it successors. present document beyond just making use of the extension points
provided here. New version numbers can only be defined in an RFC
that updates this specification or it successors.
The Name value is concatenated to the Base Name value to get the name The Name value is concatenated to the Base Name value to yield the
of the sensor. The resulting name needs to uniquely identify and name of the sensor. The resulting concatenated name needs to
differentiate the sensor from all others. It is RECOMMENDED that the uniquely identify and differentiate the sensor from all others. The
full names are represented as URIs [RFC3986] or URNs [RFC2141]. One concatenated name MUST consist only of characters out of the set "A"
way to create a unique name is to include some bit string that has to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_";
guaranteed uniqueness (such as a 1-wire address) that is assigned to furthermore, it MUST start with a character out of the set "A" to
the device. Some of the examples in this draft use the device URN "Z", "a" to "z", or "0" to "9". This restricted character set was
type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are chosen so that concatenated names can be used directly within various
another way to generate a unique name. Note that long-term stable URI schemes (including segments of an HTTP path with no special
unique identifiers are problematic for privacy reasons and should be encoding) and can be used directly in many databases and analytic
used with care or avoided as described in [RFC7721]. systems. [RFC5952] contains advice on encoding an IPv6 address in a
name. See Section 14 for privacy considerations that apply to the
use of long-term stable unique identifiers.
The resulting concatenated name MUST consist only of characters out Although it is RECOMMENDED that concatenated names are represented as
of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or URIs [RFC3986] or URNs [RFC8141], the restricted character set
"_" and it MUST start with a character out of the set "A" to "Z", "a" specified above puts strict limits on the URI schemes and URN
to "z", or "0" to "9". This restricted character set was chosen so namespaces that can be used. As a result, implementers need to take
that these names can be directly used as in other types of URI care in choosing the naming scheme for concatenated names, because
including segments of an HTTP path with no special encoding and can such names both need to be unique and need to conform to the
be directly used in many databases and analytic systems. [RFC5952] restricted character set. One approach is to include a bit string
contains advice on encoding an IPv6 address in a name. that has guaranteed uniqueness (such as a 1-wire address). Some of
the examples within this document use the device URN namespace as
specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another
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
of URIs with characters incompatible with this set, and possible
mapping rules between the two, are outside of the scope of the
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
indicates that the sensor does not know the absolute time and the indicates that the sensor does not know the absolute time and the
measurement was made roughly "now". A negative value is used to measurement was made roughly "now". A negative value is used to
indicate seconds in the past from roughly "now". A positive value is indicate seconds in the past from roughly "now". A positive value is
skipping to change at page 8, line 43 skipping to change at page 9, line 5
If the Base Value or Value is not present, the missing field(s) are If the Base Value or Value is not present, the missing field(s) are
considered to have a value of zero. The Base Value and Value are considered to have a value of zero. The Base Value and Value are
added together to get the value of the measurement. added together to get the value of the measurement.
Representing the statistical characteristics of measurements, such as Representing the statistical characteristics of measurements, such as
accuracy, can be very complex. Future specification may add new accuracy, can be very complex. Future specification may add new
fields to provide better information about the statistical properties fields to provide better information about the statistical properties
of the measurement. of the measurement.
In summary, the structure of a SenML record is laid out to support a
single measurement per record. If multiple data values are measured
at the same time (e.g., air pressure and altitude), they are best
kept as separate records linked through their Time value; this is
even true where one of the data values is more "meta" than others
(e.g., describes a condition that influences other measurements at
the same time).
4.4. Resolved Records 4.4. 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 and has no relative times, but the base values of the any base values, i.e., labels starting with the character 'b', except
SenML Pack (if any) are applied to the Record. That is, name and for Version fields (see below), and has no relative times. To
base name are concatenated, base time is added to the time of the resolve the records, the base values of the SenML Pack (if any) are
Record, if the Record did not contain Unit the Base Unit is applied applied to the Record. That is, name and base name are concatenated,
to the record, etc. In addition the records need to be in base time is added to the time of the Record, if the Record did not
chronological order. An example of this is show in Section 5.1.4. contain Unit the Base Unit is applied to the record, etc. In
addition the records need to be in chronological order. An example
of this is show in Section 5.1.4.
The Version field MUST NOT be present in resolved records if the
SenML version defined in this document is used and MUST be present
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.5. 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
skipping to change at page 9, line 33 skipping to change at page 10, line 12
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.6. 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). names) to given values at the given time(s). The semantics of the
target resource supporting this usage can be described, e.g., using
[I-D.ietf-core-interfaces]. Examples of actuation usage are shown in
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 1, 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 |
+---------------+-------+---------+ +---------------+-------+---------+
skipping to change at page 10, line 23 skipping to change at page 10, line 41
| Version | bver | Number | | Version | bver | Number |
| Name | n | String | | Name | n | String |
| 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 |
| Link | l | String |
+---------------+-------+---------+ +---------------+-------+---------+
Table 1: JSON SenML Labels Table 1: 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].
skipping to change at page 11, line 39 skipping to change at page 12, line 4
{"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09, {"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,
"bu":"A","bver":5, "bu":"A","bver":5,
"n":"voltage","u":"V","v":120.1}, "n":"voltage","u":"V","v":120.1},
{"n":"current","t":-5,"v":1.2}, {"n":"current","t":-5,"v":1.2},
{"n":"current","t":-4,"v":1.3}, {"n":"current","t":-4,"v":1.3},
{"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 a
separate media type to indicate Sensor Streaming Measurement Lists separate media type to indicate Sensor Streaming Measurement Lists
(SensML) for this usage (see Section 12.3.1). 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 13, line 11 skipping to change at page 13, line 31
The size of this example represented in various forms, as well as The size of this example represented in various forms, as well as
that form compressed with gzip is given in the following table. that form compressed with gzip is given in the following table.
+----------+------+-----------------+ +----------+------+-----------------+
| 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 | 162 | 185 | | EXI | 161 | 184 |
+----------+------+-----------------+ +----------+------+-----------------+
Table 2: Size Comparisons Table 2: 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.
[ [
skipping to change at page 16, line 34 skipping to change at page 17, line 23
| Base Sum | bs | -6 | | Base Sum | bs | -6 |
| Name | n | 0 | | Name | n | 0 |
| Units | u | 1 | | Units | 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 |
| Link | l | 9 |
+---------------+-------+------------+ +---------------+-------+------------+
Table 3: CBOR representation: integers for map keys Table 3: 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.
skipping to change at page 17, line 19 skipping to change at page 18, line 4
0040 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 06 |fffff..gcurrent.| 0040 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 06 |fffff..gcurrent.|
0050 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 75 |$..?.333333..gcu| 0050 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 75 |$..?.333333..gcu|
0060 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc cc |rrent.#..?......| 0060 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc cc |rrent.#..?......|
0070 cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb 3f |...gcurrent."..?| 0070 cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb 3f |...gcurrent."..?|
0080 f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e |.ffffff..gcurren| 0080 f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e |.ffffff..gcurren|
0090 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 6e |t.!..>...gcurren| 0090 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 6e |t.!..>...gcurren|
00a0 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 67 |t. ..?.........g| 00a0 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 67 |t. ..?.........g|
00b0 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 33 |current....?.333| 00b0 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 33 |current....?.333|
00c0 33 33 33 |333| 00c0 33 33 33 |333|
00c3 00c3
In CBOR diagnostic notation (Section 6 of [RFC7049]), this is:
[{-2: "urn:dev:ow:10e2073a0108006:",
-3: 1276020076.001, -4: "A", -1: 5, 0: "voltage", 1: "V", 2: 120.1},
{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: -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 [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]. defined in Section 5 of [RFC4648].
skipping to change at page 18, line 23 skipping to change at page 19, line 23
| Base Version | bver | int | | Base Version | bver | int |
| Name | n | string | | Name | n | string |
| 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 |
| Link | l | string |
+---------------+-------+---------+ +---------------+-------+---------+
Table 4: XML SenML Labels Table 4: 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 }?,
attribute bs { xsd:double }?, attribute bs { xsd:double }?,
attribute bu { xsd:string }?, attribute bu { xsd:string }?,
attribute bver { xsd:int }?, attribute bver { xsd:int }?,
attribute l { xsd:string }?,
attribute n { xsd:string }?, attribute n { xsd:string }?,
attribute s { xsd:double }?, attribute s { xsd:double }?,
attribute t { xsd:double }?, attribute t { xsd:double }?,
attribute u { xsd:string }?, attribute u { xsd:string }?,
attribute ut { xsd:double }?, attribute ut { xsd:double }?,
attribute v { xsd:double }?, attribute v { xsd:double }?,
attribute vb { xsd:boolean }?, attribute vb { xsd:boolean }?,
attribute vs { xsd:string }?, attribute vs { xsd:string }?,
attribute vd { xsd:string }? attribute vd { xsd:string }?
skipping to change at page 20, line 24 skipping to change at page 21, line 23
targetNamespace="urn:ietf:params:xml:ns:senml" targetNamespace="urn:ietf:params:xml:ns:senml"
xmlns:ns1="urn:ietf:params:xml:ns:senml"> xmlns:ns1="urn:ietf:params:xml:ns:senml">
<xs:element name="senml"> <xs:element name="senml">
<xs:complexType> <xs:complexType>
<xs:attribute name="bn" type="xs:string" /> <xs:attribute name="bn" type="xs:string" />
<xs:attribute name="bt" type="xs:double" /> <xs:attribute name="bt" type="xs:double" />
<xs:attribute name="bv" type="xs:double" /> <xs:attribute name="bv" type="xs:double" />
<xs:attribute name="bs" type="xs:double" /> <xs:attribute name="bs" type="xs:double" />
<xs:attribute name="bu" type="xs:string" /> <xs:attribute name="bu" type="xs:string" />
<xs:attribute name="bver" type="xs:int" /> <xs:attribute name="bver" type="xs:int" />
<xs:attribute name="l" type="xs:string" />
<xs:attribute name="n" type="xs:string" /> <xs:attribute name="n" type="xs:string" />
<xs:attribute name="s" type="xs:double" /> <xs:attribute name="s" type="xs:double" />
<xs:attribute name="t" type="xs:double" /> <xs:attribute name="t" type="xs:double" />
<xs:attribute name="u" type="xs:string" /> <xs:attribute name="u" type="xs:string" />
<xs:attribute name="ut" type="xs:double" /> <xs:attribute name="ut" type="xs:double" />
<xs:attribute name="v" type="xs:double" /> <xs:attribute name="v" type="xs:double" />
<xs:attribute name="vb" type="xs:boolean" /> <xs:attribute name="vb" type="xs:boolean" />
<xs:attribute name="vs" type="xs:string" /> <xs:attribute name="vs" type="xs:string" />
<xs:attribute name="vd" type="xs:string" /> <xs:attribute name="vd" type="xs:string" />
</xs:complexType> </xs:complexType>
skipping to change at page 21, line 10 skipping to change at page 22, line 4
The following shows a hexdump of the EXI produced from encoding the The following shows a hexdump of the EXI produced from encoding the
following XML example. Note this example is the same information as following XML example. Note this example is the same information as
the first example in Section 5.1.2 in JSON format. the first example in Section 5.1.2 in JSON format.
<sensml xmlns="urn:ietf:params:xml:ns:senml"> <sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml bn="urn:dev:ow:10e2073a01080063:" n="voltage" u="V" <senml bn="urn:dev:ow:10e2073a01080063:" n="voltage" u="V"
v="120.1"></senml> v="120.1"></senml>
<senml n="current" u="A" v="1.2"></senml> <senml n="current" u="A" v="1.2"></senml>
</sensml> </sensml>
Which compresses with EXI to the following displayed in hexdump: Which compresses with EXI to the following displayed in hexdump:
0000 a0 30 0d 84 80 79 d5 c9 b8 e9 91 95 d8 e9 bd dc |.0...y..........| 0000 a0 30 0d 84 80 f3 ab 93 71 d3 23 2b b1 d3 7b b9 |.0......q.#+..{.|
0010 e8 c4 c1 94 c8 c0 dc cd 84 c0 c4 c0 e0 c0 c0 d8 |................| 0010 d1 89 83 29 91 81 b9 9b 09 81 89 81 c1 81 81 b1 |...)............|
0020 cc e9 82 5d 9b db 1d 18 59 d9 48 0d 58 ac 42 60 |...]....Y.H.X.B`| 0020 99 d2 84 bb 37 b6 3a 30 b3 b2 90 1a b1 58 84 c0 |....7.:0.....X..|
0030 18 e1 2c 6e ae 4e 4c ad ce 84 06 82 41 90 0e |..,n.NL.....A..| 0030 33 04 b1 ba b9 39 32 b7 3a 10 1a 09 06 40 38 |3....92.:....@8|
003f 003f
The above example used the bit packed form of EXI but it is also The above example used the bit packed form of EXI but it is also
possible to use a byte packed form of EXI which can makes it easier possible to use a byte packed form of EXI which can makes it easier
for a simple sensor to produce valid EXI without really implementing for a simple sensor to produce valid EXI without really implementing
EXI. Consider the example of a temperature sensor that produces a EXI. Consider the example of a temperature sensor that produces a
value in tenths of degrees Celsius over a range of 0.0 to 55.0. It value in tenths of degrees Celsius over a range of 0.0 to 55.0. It
would produce an XML SenML file such as: would produce an XML SenML file such as:
<sensml xmlns="urn:ietf:params:xml:ns:senml"> <sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml n="urn:dev:ow:10e2073a01080063" u="Cel" v="23.1"></senml> <senml n="urn:dev:ow:10e2073a01080063" u="Cel" v="23.1"></senml>
</sensml> </sensml>
The compressed form, using the byte alignment option of EXI, for the The compressed form, using the byte alignment option of EXI, for the
above XML is the following: above XML is the following:
0000 a0 00 48 80 6c 20 01 07 1d 75 72 6e 3a 64 65 76 |..H.l ...urn:dev| 0000 a0 00 48 80 6c 20 01 06 1d 75 72 6e 3a 64 65 76 |..H.l ...urn:dev|
0010 3a 6f 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 |:ow:10e2073a0108| 0010 3a 6f 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 |:ow:10e2073a0108|
0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| 0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......|
0030 01 |.| 0030 01 |.|
0031 0031
A small temperature sensor device that only generates this one EXI A small temperature sensor device that only generates this one EXI
file does not really need an full EXI implementation. It can simply file does not really need an full EXI implementation. It can simply
hard code the output replacing the 1-wire device ID starting at byte hard code the output replacing the 1-wire device ID starting at byte
0x20 and going to byte 0x2F with it's device ID, and replacing the 0x20 and going to byte 0x2F with it's device ID, and replacing the
value "0xe7 0x01" at location 0x37 and 0x38 with the current value "0xe7 0x01" at location 0x37 and 0x38 with the current
skipping to change at page 23, line 29 skipping to change at page 24, line 27
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 units set to watts, but it would put the sum of energy used in
the "s" field of the measurement. It might optionally include the 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.
Implementors 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.
Applications that use the cumulative sum values need to understand Applications that use the cumulative sum values need to understand
they are very loosely defined by this specification, and depending on they are very loosely defined by this specification, and depending on
the particular sensor implementation may behave in unexpected ways. the particular sensor implementation may behave in unexpected ways.
Applications should be able to deal with the following issues: Applications should be able to deal with the following issues:
1. Many sensors will allow the cumulative sums to "wrap" back to 1. Many sensors will allow the cumulative sums to "wrap" back to
zero after the value gets sufficiently large. zero after the value gets sufficiently large.
skipping to change at page 24, line 8 skipping to change at page 25, line 8
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 For reference, the JSON and CBOR representations can be described
with the common CDDL [I-D.greevenbosch-appsawg-cbor-cddl] with the common CDDL [I-D.ietf-cbor-cddl] specification in Figure 1.
specification in Figure 1.
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 26, line 41 skipping to change at page 27, line 41
| m/s | meter per second (velocity) | float | RFC-AAAA | | m/s | meter per second (velocity) | float | RFC-AAAA |
| m/s2 | meter per square second | float | RFC-AAAA | | m/s2 | meter per square second | float | RFC-AAAA |
| | (acceleration) | | | | | (acceleration) | | |
| m3/s | cubic meter per second (flow rate) | float | RFC-AAAA | | m3/s | cubic meter per second (flow rate) | float | RFC-AAAA |
| l/s | liter per second (flow rate)* | float | RFC-AAAA | | l/s | liter per second (flow rate)* | float | RFC-AAAA |
| W/m2 | watt per square meter (irradiance) | float | RFC-AAAA | | W/m2 | watt per square meter (irradiance) | float | RFC-AAAA |
| cd/m2 | candela per square meter | float | RFC-AAAA | | cd/m2 | candela per square meter | float | RFC-AAAA |
| | (luminance) | | | | | (luminance) | | |
| bit | bit (information content) | float | RFC-AAAA | | bit | bit (information content) | float | RFC-AAAA |
| bit/s | bit per second (data rate) | float | RFC-AAAA | | bit/s | bit per second (data rate) | float | RFC-AAAA |
| lat | degrees latitude (note 2) | float | RFC-AAAA | | lat | degrees latitude (note 1) | float | RFC-AAAA |
| lon | degrees longitude (note 2) | float | RFC-AAAA | | lon | degrees longitude (note 1) | float | RFC-AAAA |
| pH | pH value (acidity; logarithmic | float | RFC-AAAA | | pH | pH value (acidity; logarithmic | float | RFC-AAAA |
| | quantity) | | | | | quantity) | | |
| dB | decibel (logarithmic quantity) | float | RFC-AAAA | | dB | decibel (logarithmic quantity) | float | RFC-AAAA |
| dBW | decibel relative to 1 W (power | float | RFC-AAAA | | dBW | decibel relative to 1 W (power | float | RFC-AAAA |
| | level) | | | | | level) | | |
| Bspl | bel (sound pressure level; | float | RFC-AAAA | | Bspl | bel (sound pressure level; | float | RFC-AAAA |
| | logarithmic quantity)* | | | | | logarithmic quantity)* | | |
| count | 1 (counter value) | float | RFC-AAAA | | count | 1 (counter value) | float | RFC-AAAA |
| / | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | | / | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA |
| | note 1) | | | | | note 2) | | |
| % | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | | % | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA |
| | note 1)* | | | | | note 2)* | | |
| %RH | Percentage (Relative Humidity) | float | RFC-AAAA | | %RH | Percentage (Relative Humidity) | float | RFC-AAAA |
| %EL | Percentage (remaining battery | float | RFC-AAAA | | %EL | Percentage (remaining battery | float | RFC-AAAA |
| | energy level) | | | | | energy level) | | |
| EL | seconds (remaining battery energy | float | RFC-AAAA | | EL | seconds (remaining battery energy | float | RFC-AAAA |
| | 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 5
o Note 1: A value of 0.0 indicates the switch is off while 1.0 o Note 1: Assumed to be in WGS84 unless another reference frame is
known for the sensor.
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!
o Note 2: Assumed to be in WGS84 unless another reference frame is New entries can be added to the registration by Expert Review as
known for the sensor. defined in [RFC8126]. Experts should exercise their own good
judgment but need to consider the following guidelines:
New entries can be added to the registration by either Expert Review
or IESG Approval as defined in [RFC5226]. Experts should exercise
their own good 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. Units should define the semantic information and be chosen
carefully. Implementors 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 28, line 16 skipping to change at page 29, line 16
recommended. Instead one can represent the value using recommended. Instead one can represent the value using
scientific notation such a 1.2e3. The "kg" unit is exception to scientific notation such a 1.2e3. The "kg" unit is exception to
this rule since it is an SI base unit; the "g" unit is provided this rule since it is an SI base unit; the "g" unit is provided
for legacy compatibility. for legacy compatibility.
5. For a given type of measurement, there will only be one unit 5. For a given type of measurement, there will only be one unit
type defined. So for length, meters are defined and other type defined. So for length, meters are defined and other
lengths such as mile, foot, light year are not allowed. For lengths such as mile, foot, light year are not allowed. For
most cases, the SI unit is preferred. most cases, the SI unit is preferred.
(Note that some amount of judgment will be required here, as
even SI itself is not entirely consistent in this respect. For
instance, for temperature [ISO-80000-5] defines a quantity, item
5-1 (thermodynamic temperature), and a corresponding unit 5-1.a
(Kelvin), and then goes ahead to define another quantity right
besides that, item 5-2 ("Celsius temperature"), and the
corresponding unit 5-2.a (degree Celsius). The latter quantity
is defined such that it gives the thermodynamic temperature as a
delta from T0 = 275.15 K. ISO 80000-5 is defining both units
side by side, and not really expressing a preference. This
level of recognition of the alternative unit degree Celsius is
the reason why Celsius temperatures exceptionally seem
acceptable in the SenML units list alongside Kelvin.)
6. Symbol names that could be easily confused with existing common 6. Symbol names that could be easily confused with existing common
units or units combined with prefixes should be avoided. For units or units combined with prefixes should be avoided. For
example, selecting a unit name of "mph" to indicate something example, selecting a unit name of "mph" to indicate something
that had nothing to do with velocity would be a bad choice, as that had nothing to do with velocity would be a bad choice, as
"mph" is commonly used to mean miles per hour. "mph" is commonly used to mean miles per hour.
7. The following should not be used because the are common SI 7. The following should not be used because the are common SI
prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z,
y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi.
skipping to change at page 29, line 5 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 | XML Type | ID | Note | | Name | Label | CBOR | Type | EXI ID | Note |
+---------------+-------+------+----------+----+---------+ +---------------+-------+------+---------+--------+---------+
| Base Name | bn | -2 | string | a | RFCXXXX | | Base Name | bn | -2 | string | a | RFCXXXX |
| Base Sum | bs | -6 | double | a | RFCXXXX | | Base Sum | bs | -6 | double | a | RFCXXXX |
| Base Time | bt | -3 | double | a | RFCXXXX | | Base Time | bt | -3 | double | a | RFCXXXX |
| Base Unit | bu | -4 | string | a | RFCXXXX | | Base Unit | bu | -4 | string | a | RFCXXXX |
| Base Value | bv | -5 | double | a | RFCXXXX | | Base Value | bv | -5 | double | a | RFCXXXX |
| Base Version | bver | -1 | int | a | RFCXXXX | | Base Version | bver | -1 | int | a | RFCXXXX |
| Boolean Value | vb | 4 | boolean | a | RFCXXXX | | Boolean Value | vb | 4 | boolean | a | RFCXXXX |
| Data Value | vd | 8 | string | a | RFCXXXX | | Data Value | vd | 8 | string | a | RFCXXXX |
| Name | n | 0 | string | a | RFCXXXX | | Name | n | 0 | string | a | RFCXXXX |
| String Value | vs | 3 | string | a | RFCXXXX | | String Value | vs | 3 | string | a | RFCXXXX |
| Time | t | 6 | double | a | RFCXXXX | | Time | t | 6 | double | a | RFCXXXX |
| Unit | u | 1 | string | a | RFCXXXX | | Unit | u | 1 | string | a | RFCXXXX |
| Update Time | ut | 7 | double | a | RFCXXXX | | Update Time | ut | 7 | double | a | RFCXXXX |
| Value | v | 2 | double | a | RFCXXXX | | Value | v | 2 | double | a | RFCXXXX |
| Value Sum | s | 5 | double | a | RFCXXXX | | Value Sum | s | 5 | double | a | RFCXXXX |
| Link | l | 9 | string | a | RFCXXXX | +---------------+-------+------+---------+--------+---------+
+---------------+-------+------+----------+----+---------+
Table 6: SenML Labels Table 6: SenML Labels
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 ID fields contains the EXI schemaId encoding for any new labels. The EXI ID column contains the EXI
value of the first Schema which includes this label or is empty if schemaId value of the first Schema which includes this label or is
this label was not intended for use with EXI. The Note field SHOULD empty if this label was not intended for use with EXI. The Note
contain information about where to find out more information about field SHOULD contain information about where to find out more
this label. information about 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 loose 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 either Expert Review
or IESG Approval as defined in [RFC5226]. Experts should exercise or IESG Approval as defined in [RFC8126]. Experts should exercise
their own good judgment but need to consider that shorter labels their own good judgment but need to consider that shorter labels
should have more strict review. should have more strict review. New entries should not be made that
counteract the advice at the end of Section 4.3.
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 character 'b'. Regular labels MUST NOT start with MUST start with the character 'b'. Regular labels MUST NOT start
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
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
skipping to change at page 42, line 5 skipping to change at page 43, line 20
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.
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
unique identifiers can be problematic for privacy reasons [RFC6973],
depending on the application and the potential of these identifiers
to be used in correlation with other information. They should be
used with care or avoided as for example described for IPv6 addresses
in [RFC7721].
15. Acknowledgement 15. Acknowledgement
We would like to thank Alexander Pelov, Andrew McClure, Andrew We would like to thank Alexander Pelov, Andrew McClure, Andrew
Mcgregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, McGregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves,
Daniel Peintner, Jan-Piet Mens, Joe Hildebrand, John Klensin, Karl Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe Hildebrand, John
Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Campbell, Martin Klensin, Karl Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay
Thomson, Michael Koster, and Stephen Farrell, for their review Campbell, Martin Thomson, Michael Koster, Peter Saint-Andre, and
comments. 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,
"Standard for Binary Floating-Point Arithmetic", "Standard for Binary Floating-Point Arithmetic", IEEE
IEEE Standard 754, August 1985. Standard 754, August 1985.
[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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997, <https://www.rfc-editor.org/info/
<http://www.rfc-editor.org/info/rfc2119>. rfc2119>.
[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, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
<http://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,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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, Specifications and Registration Procedures", BCP 13, RFC
RFC 6838, DOI 10.17487/RFC6838, January 2013, 6838, DOI 10.17487/RFC6838, January 2013,
<http://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, <http://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 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 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, Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
DOI 10.17487/RFC7252, June 2014, RFC7252, June 2014, <https://www.rfc-editor.org/info/
<http://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, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7303>. editor.org/info/rfc7303>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
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-03 Names for Device Identifiers", draft-arkko-core-dev-urn-05
(work in progress), July 2012. (work in progress), October 2017.
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "CBOR 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-greevenbosch-appsawg- express CBOR data structures", draft-ietf-cbor-cddl-00
cbor-cddl-10 (work in progress), March 2017. (work in progress), July 2017.
[I-D.ietf-core-links-json] [I-D.ietf-core-interfaces]
Li, K., Rahman, A., and C. Bormann, "Representing Shelby, Z., Vial, M., Koster, M., Groves, C., Zhu, J., and
Constrained RESTful Environments (CoRE) Link Format in B. Silverajan, "Reusable Interface Definitions for
JSON and CBOR", draft-ietf-core-links-json-08 (work in Constrained RESTful Environments", draft-ietf-core-
progress), April 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
Applications in Bridged Local Area Networks", 2011. Applications in Bridged Local Area Networks", 2011.
[IEEE802.1ba-2011] [IEEE802.1ba-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks--Audio Video Bridging (AVB) Systems", 2011. networks--Audio Video Bridging (AVB) Systems", 2011.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, [ISO-80000-5]
May 1997, <http://www.rfc-editor.org/info/rfc2141>. "Quantities and units - Part 5: Thermodynamics", ISO
80000-5, Edition 1.0, May 2007.
[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, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<http://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, Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI
DOI 10.17487/RFC4122, July 2005, 10.17487/RFC4122, July 2005, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4122>. editor.org/info/rfc4122>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[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, Address Text Representation", RFC 5952, DOI 10.17487/
DOI 10.17487/RFC5952, August 2010, RFC5952, August 2010, <https://www.rfc-editor.org/info/
<http://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,
<http://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, DOI
10.17487/RFC6973, July 2013, <https://www.rfc-
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, Identifiers for the text/csv Media Type", RFC 7111, DOI
DOI 10.17487/RFC7111, January 2014, 10.17487/RFC7111, January 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7111>. editor.org/info/rfc7111>.
[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,
<http://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<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
of Measure (UCUM)", Regenstrief Institute and Indiana of Measure (UCUM)", Regenstrief Institute and Indiana
University School of Informatics, 2013, University School of Informatics, 2013,
<http://unitsofmeasure.org/ucum.html>. <http://unitsofmeasure.org/ucum.html>.
Appendix A. Links Extension
A field to support a link extension for SenML is defined as a string
field by this specification. The link extension can be used for
additional information about a SenML Record. The definition and
usage of the contents of this value are specified in
[I-D.ietf-core-links-json].
For JSON and XML the field has a label of "l" and a value that is a
string.
The following shows an example of the links extension.
[
{"bn":"urn:dev:ow:10e2073a01080063:","bt":1.320078429e+09,
"l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]",
"n":"temperature","u":"Cel","v":27.2},
{"n":"humidity","u":"%RH","v":80}
]
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Cisco
400 3rd Avenue SW 400 3rd Avenue SW
Calgary, AB T2P 4H2 Calgary, AB T2P 4H2
Canada Canada
Email: fluffy@iii.ca Email: fluffy@iii.ca
Zach Shelby Zach Shelby
ARM ARM
150 Rose Orchard 150 Rose Orchard
San Jose 95134 San Jose 95134
USA USA
Phone: +1-408-203-9434 Phone: +1-408-203-9434
Email: zach.shelby@arm.com Email: zach.shelby@arm.com
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
 End of changes. 68 change blocks. 
220 lines changed or deleted 262 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/