draft-ietf-core-senml-08.txt   draft-ietf-core-senml-09.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: November 24, 2017 ARM Expires: December 31, 2017 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
May 23, 2017 June 29, 2017
Media Types for Sensor Measurement Lists (SenML) Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-08 draft-ietf-core-senml-09
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 November 24, 2017. This Internet-Draft will expire on December 31, 2017.
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 5, line 48 skipping to change at page 5, line 48
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.
4. SenML Structure and Semantics 4. SenML Structure and Semantics
Each SenML Pack carries a single array that represents a set of Each SenML Pack carries a single array that represents a set of
measurements and/or parameters. This array contains a series of measurements and/or parameters. This array contains a series of
SenML Records with several attributes described below. There are two SenML Records with several attributes described below. There are two
kind of attributes: base and regular. The base attributes can be kind of attributes: base and regular. The base attributes can be
included in the any SenML Record and they apply to the entries in the included in any SenML Record and they apply to the entries in the
Record. Each base attribute also applies to all Records after it up Record. Each base attribute also applies to all Records after it up
to, but not including, the next Record that has that same base to, but not including, the next Record that has that same base
attribute. All base attributes are optional. Regular attributes can attribute. All base attributes are optional. Regular attributes can
be included in any SenML Record and apply only to that Record. be included in any SenML Record and apply only to that Record.
4.1. Base attributes 4.1. Base attributes
Base Name: This is a string that is prepended to the names found in Base Name: This is a string that is prepended to the names found in
the entries. the entries.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Name: Name of the sensor or parameter. When appended to the Base Name: Name of the sensor or parameter. When appended to the Base
Name attribute, this must result in a globally unique identifier Name attribute, this must result in a globally unique identifier
for the resource. The name is optional, if the Base Name is for the resource. The name is optional, if the Base Name is
present. If the name is missing, Base Name must uniquely identify present. If the name is missing, Base Name must uniquely identify
the resource. This can be used to represent a large array of the resource. This can be used to represent a large array of
measurements from the same sensor without having to repeat its measurements from the same sensor without having to repeat its
identifier on every measurement. identifier on every measurement.
Unit: Units for a measurement value. Optional. Unit: Units for a measurement value. Optional.
Value Value of the entry. Optional if a Sum value is present, Value: Value of the entry. Optional if a Sum value is present,
otherwise required. Values are represented using basic data otherwise required. Values are represented using basic data
types. This specification defines floating point numbers ("v" types. This specification defines floating point numbers ("v"
field for "Value"), booleans ("vb" for "Boolean Value"), strings field for "Value"), booleans ("vb" for "Boolean Value"), strings
("vs" for "String Value") and binary data ("vd" for "Data Value"). ("vs" for "String Value") and binary data ("vd" for "Data Value").
Exactly one value field MUST appear unless there is Sum field in Exactly one value field MUST appear unless there is Sum field in
which case it is allowed to have no Value field. which case it is allowed to have no Value field.
Sum: Integrated sum of the values over time. Optional. This Sum: Integrated sum of the values over time. Optional. This
attribute is in the units specified in the Unit value multiplied attribute is in the units specified in the Unit value multiplied
by seconds. by seconds.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
Systems reading one of the objects MUST check for the Version Systems reading one of the objects MUST check for the Version
attribute. If this value is a version number larger than the version attribute. If this value is a version number larger than the version
which the system understands, the system SHOULD NOT use this object. which the system understands, the system SHOULD NOT use this object.
This allows the version number to indicate that the object contains This allows the version number to indicate that the object contains
mandatory to understand attributes. New version numbers can only be mandatory to understand attributes. New version numbers can only be
defined in an RFC that updates this specification or it successors. 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 get the name
of the sensor. The resulting name needs to uniquely identify and of the sensor. The resulting name needs to uniquely identify and
differentiate the sensor from all others. It is RECOMMENDED that the differentiate the sensor from all others. It is RECOMMENDED that the
full names are represented as URIs or URNs [RFC2141]. One way to full names are represented as URIs [RFC3986] or URNs [RFC2141]. One
create a unique name is to include some bit string that has way to create a unique name is to include some bit string that has
guaranteed uniqueness (such as a 1-wire address) that is assigned to guaranteed uniqueness (such as a 1-wire address) that is assigned to
the device. Some of the examples in this draft use the device URN the device. Some of the examples in this draft use the device URN
type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are
another way to generate a unique name. Note that long-term stable another way to generate a unique name. Note that long-term stable
unique identifiers are problematic for privacy reasons and should be unique identifiers are problematic for privacy reasons and should be
used with care or avoided as described in [RFC7721]. used with care or avoided as described in [RFC7721].
The resulting concatenated name MUST consist only of characters out The resulting concatenated name MUST consist only of characters out
of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_"
and it MUST start with a character out of the set "A" to "Z", "a" to and it MUST start with a character out of the set "A" to "Z", "a" to
skipping to change at page 24, line 11 skipping to change at page 24, line 11
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.greevenbosch-appsawg-cbor-cddl]
specification in Figure 1. specification in Figure 1.
SenML-Pack = [ record, * 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
? n => tstr, ; Name ? n => tstr, ; Name
? u => tstr, ; Units ? u => tstr, ; Units
skipping to change at page 24, line 36 skipping to change at page 24, line 36
? ( v => numeric // ; Numeric Value ? ( v => numeric // ; Numeric Value
vs => tstr // ; String Value vs => tstr // ; String Value
vb => bool // ; Boolean Value vb => bool // ; Boolean Value
vd => binary-value ) ; Data Value vd => binary-value ) ; Data Value
* key-value-pair * key-value-pair
} }
; now define the generic versions ; now define the generic versions
key-value-pair = ( label => value ) key-value-pair = ( label => value )
label = tstr .regexp "[A-Za-z0-9][-_:.A-Za-z0-9]*" / uint label = non-b-label / b-label
non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint
b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint
value = tstr / binary-value / numeric / bool value = tstr / binary-value / numeric / bool
numeric = number / decfrac numeric = number / decfrac
Figure 1: Common CDDL specification for CBOR and JSON SenML Figure 1: Common CDDL specification for CBOR and JSON SenML
For JSON, we use text labels and base64url-encoded binary data For JSON, we use text labels and base64url-encoded binary data
(Figure 2). (Figure 2).
bver = "bver" n = "n" s = "s" bver = "bver" n = "n" s = "s"
skipping to change at page 26, line 46 skipping to change at page 26, line 46
| 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 2) | float | RFC-AAAA |
| lon | degrees longitude (note 2) | float | RFC-AAAA | | lon | degrees longitude (note 2) | 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 |
| | 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 1) | | |
| % | 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 1)* | | |
| %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) | | |
skipping to change at page 42, line 44 skipping to change at page 42, line 44
[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,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-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>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <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 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <http://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,
skipping to change at page 45, line 14 skipping to change at page 45, line 14
and usage of the contents of this value are specified in and usage of the contents of this value are specified in
[I-D.ietf-core-links-json]. [I-D.ietf-core-links-json].
For JSON and XML the attribute has a label of "l" and a value that is For JSON and XML the attribute has a label of "l" and a value that is
a string. a string.
The following shows an example of the links extension. The following shows an example of the links extension.
[ [
{"bn":"urn:dev:ow:10e2073a01080063:","bt":1.320078429e+09, {"bn":"urn:dev:ow:10e2073a01080063:","bt":1.320078429e+09,
"l":"[{\"href\":\"humidity\",\"foo\":\"bar1\"}", "l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]",
"n":"temperature","u":"Cel","v":27.2}, "n":"temperature","u":"Cel","v":27.2},
{"n":"humidity","u":"%RH","v":80} {"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
 End of changes. 12 change blocks. 
12 lines changed or deleted 16 lines changed or added

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