draft-ietf-core-senml-07.txt   draft-ietf-core-senml-08.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 5, 2017 ARM Expires: November 24, 2017 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
May 4, 2017 May 23, 2017
Media Types for Sensor Measurement Lists (SenML) Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-07 draft-ietf-core-senml-08
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 5, 2017. This Internet-Draft will expire on November 24, 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 2, line 48 skipping to change at page 2, line 48
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 13 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 13
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 14 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 14
6. CBOR Representation (application/senml+cbor) . . . . . . . . 15 6. CBOR Representation (application/senml+cbor) . . . . . . . . 15
7. XML Representation (application/senml+xml) . . . . . . . . . 17 7. XML Representation (application/senml+xml) . . . . . . . . . 17
8. EXI Representation (application/senml+exi) . . . . . . . . . 19 8. EXI Representation (application/senml+exi) . . . . . . . . . 19
9. Fragment Identification Methods . . . . . . . . . . . . . . . 22 9. Fragment Identification Methods . . . . . . . . . . . . . . . 22
9.1. Fragment Identification Examples . . . . . . . . . . . . 22 9.1. Fragment Identification Examples . . . . . . . . . . . . 22
10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 23 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 23
11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 25
12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 29 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 28
12.3. Media Type Registration . . . . . . . . . . . . . . . . 30 12.3. Media Type Registration . . . . . . . . . . . . . . . . 30
12.3.1. senml+json Media Type Registration . . . . . . . . . 30 12.3.1. senml+json Media Type Registration . . . . . . . . . 30
12.3.2. sensml+json Media Type Registration . . . . . . . . 32 12.3.2. sensml+json Media Type Registration . . . . . . . . 32
12.3.3. senml+cbor Media Type Registration . . . . . . . . . 33 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 33
12.3.4. sensml+cbor Media Type Registration . . . . . . . . 34 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 34
12.3.5. senml+xml Media Type Registration . . . . . . . . . 36 12.3.5. senml+xml Media Type Registration . . . . . . . . . 35
12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37
12.3.7. senml+exi Media Type Registration . . . . . . . . . 38 12.3.7. senml+exi Media Type Registration . . . . . . . . . 38
12.3.8. sensml+exi Media Type Registration . . . . . . . . . 40 12.3.8. sensml+exi Media Type Registration . . . . . . . . . 39
12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41
12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 42 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . 42 16.1. Normative References . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . 44 16.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Links Extension . . . . . . . . . . . . . . . . . . 45 Appendix A. Links Extension . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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
skipping to change at page 4, line 24 skipping to change at page 4, line 24
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 on mesh networks from large numbers of constrained
devices. Keeping the total size of payload under 80 bytes makes this devices. Keeping the total size of payload under 80 bytes makes this
easy to use on a wireless mesh network. It is always difficult to easy to use on a wireless mesh network. It is always difficult to
define what small code is, but there is a desire to be able to define what small code is, but there is a desire to be able to
implement this in roughly 1 KB of flash on a 8 bit microprocessor. implement this in roughly 1 KB of flash on a 8 bit microprocessor.
Experience with Google power meter and large scale deployments has Experience with power meters and other large scale deployments has
indicated that the solution needs to support allowing multiple indicated that the solution needs to support allowing multiple
measurements to be batched into a single HTTP or CoAP request. This measurements to be batched into a single HTTP or CoAP request. This
"batch" upload capability allows the server side to efficiently "batch" upload capability allows the server side to efficiently
support a large number of devices. It also conveniently supports support a large number of devices. It also conveniently supports
batch transfers from proxies and storage devices, even in situations batch transfers from proxies and storage devices, even in situations
where the sensor itself sends just a single data item at a time. The where the sensor itself sends just a single data item at a time. The
multiple measurements could be from multiple related sensors or from multiple measurements could be from multiple related sensors or from
the same sensor but at different times. 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
skipping to change at page 5, line 47 skipping to change at page 5, line 47
SenML Record: One measurement or configuration instance in time SenML Record: One measurement or configuration instance in time
presented using the SenML data model. presented using the SenML data model.
SenML Pack: One or more SenML Records in an array structure. SenML Pack: One or more SenML Records in an array structure.
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 only kind of attributes: base and regular. The base attributes can be
be included in the first SenML Record and they apply to the entries included in the any SenML Record and they apply to the entries in the
in all Records. All base attributes are optional. Regular Record. Each base attribute also applies to all Records after it up
attributes can be included in any SenML Record and apply only to that to, but not including, the next Record that has that same base
Record. attribute. All base attributes are optional. Regular attributes can
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.
Base Time: A base time that is added to the time found in an entry. Base Time: A base time that is added to the time found in an entry.
Base Unit: A base unit that is assumed for all entries, unless Base Unit: A base unit that is assumed for all entries, unless
otherwise indicated. If a record does not contain a Unit value, otherwise indicated. If a record does not contain a Unit value,
skipping to change at page 6, line 38 skipping to change at page 6, line 38
4.2. Regular attributes 4.2. Regular attributes
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. If the Record has Unit: Units for a measurement value. Optional.
no Unit, the Base Unit is used as the Unit. Having no Unit and no
Base Unit is allowed.
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
skipping to change at page 7, line 29 skipping to change at page 7, line 27
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. If the object is a differentiate the sensor from all others. It is RECOMMENDED that the
representation resulting from the request of a URI [RFC3986], then in full names are represented as URIs or URNs [RFC2141]. One way to
the absence of the Base Name attribute, this URI is used as the create a unique name is to include some bit string that has
default value of Base Name. Thus in this case the Name field needs guaranteed uniqueness (such as a 1-wire address) that is assigned to
to be unique for that URI, for example an index or subresource name the device. Some of the examples in this draft use the device URN
of sensors handled by the URI. 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
Alternatively, for objects not related to a URI, a unique name is unique identifiers are problematic for privacy reasons and should be
required. In any case, it is RECOMMENDED that the full names are used with care or avoided as described in [RFC7721].
represented as URIs or URNs [RFC2141]. One 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 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 another way to
generate a unique name. Note that long-term stable unique
identifiers are problematic for privacy reasons [RFC7721] and should
be used with care or avoided.
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
"z", or "0" to "9". This restricted character set was chosen so that "z", or "0" to "9". This restricted character set was chosen so that
these names can be directly used as in other types of URI including these names can be directly used as in other types of URI including
segments of an HTTP path with no special encoding and can be directly segments of an HTTP path with no special encoding and can be directly
used in many databases and analytic systems. [RFC5952] contains used in many databases and analytic systems. [RFC5952] contains
advice on encoding an IPv6 address in a name. advice on encoding an IPv6 address in a name.
If the Record has no Unit, the Base Unit is used as the Unit. Having
no Unit and no Base Unit is allowed.
If either the Base Time or Time value is missing, the missing If either the Base Time or Time value is missing, the missing
attribute is considered to have a value of zero. The Base Time and attribute 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 values are added together to get the time of measurement. A
time of zero indicates that the sensor does not know the absolute time of zero indicates that the sensor does not know the absolute
time and the measurement was made roughly "now". A negative value is time and the measurement was made roughly "now". A negative value is
used to indicate seconds in the past from roughly "now". A positive used to indicate seconds in the past from roughly "now". A positive
value is used to indicate the number of seconds, excluding leap value is used to indicate the number of seconds, excluding leap
seconds, since the start of the year 1970 in UTC. seconds, since the start of the year 1970 in UTC.
If only one of the Base Sum or Sum value is present, the missing If only one of the Base Sum or Sum value is present, the missing
attribute is considered to have a value of zero. The Base Sum and attribute is considered to have a value of zero. The Base Sum and
Sum values are added together to get the sum of measurement. If Sum values are added together to get the sum of measurement. If
neither the Base Sum or Sum are present, then the measurement does neither the Base Sum or Sum are present, then the measurement does
not have a sum value. not have a sum value.
If the Base Value or Value is not present, the missing attribute(s)
are considered to have a value of zero. The Base Value and Value are
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
attributes to provide better information about the statistical attributes to provide better information about the statistical
properties of the measurement. properties of the measurement.
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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
| 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 | 162 | 185 |
+----------+------+-----------------+ +----------+------+-----------------+
Table 2: Size Comparisons Table 2: Size Comparisons
Note the EXI sizes are not using the schema guidance so the EXI
representation could be a bit smaller.
5.1.4. Resolved Data 5.1.4. Resolved Data
The following shows the example from the previous section show in The following shows the example from the previous section show in
resolved format. resolved format.
[ [
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,
"v":20}, "v":20},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09,
"v":24.30621}, "v":24.30621},
skipping to change at page 13, line 48 skipping to change at page 13, line 48
[ [
{"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1}, {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1},
{"n":"label","vs":"Machine Room"}, {"n":"label","vs":"Machine Room"},
{"n":"open","vb":false}, {"n":"open","vb":false},
{"n":"nfv-reader","vd":"aGkgCg=="} {"n":"nfv-reader","vd":"aGkgCg=="}
] ]
5.1.6. Collection of Resources 5.1.6. Collection of Resources
The following example shows how to query one device that can provide The following example shows the results from a query to one device
multiple measurements. The example assumes that a client has fetched that aggregates multiple measurements from another devices. The
information from a device at 2001:db8::2 by performing a GET example assumes that a client has fetched information from a device
operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, at 2001:db8::2 by performing a GET operation on http://[2001:db8::2]
and has gotten two separate values as a result, a temperature and at Mon Oct 31 16:27:09 UTC 2011, and has gotten two separate values
humidity measurement. as a result, a temperature and humidity measurement as well as the
results from another device at http://[2001:db8::1] that also had a
temperature and humidity. Note that the last record would use the
Base Name from the 3rd record but the Base Time from the first
record.
[ [
{"bn":"2001:db8::2","bt":1.320078429e+09, {"bn":"2001:db8::2","bt":1.320078429e+09,
"n":"temperature","u":"Cel","v":27.2}, "n":"temperature","u":"Cel","v":25.2},
{"n":"humidity","u":"%RH","v":80} {"n":"humidity","u":"%RH","v":30},
{"bn":"2001:db8::1",
"n":"temperature","u":"Cel","v":12.3},
{"n":"humidity","u":"%RH","v":67}
] ]
5.1.7. Setting an Actuator 5.1.7. Setting an Actuator
The following example show the SenML that could be used to set the The following example show the SenML that could be used to set the
current set point of a typical residential thermostat which has a current set point of a typical residential thermostat which has a
temperature set point, a switch to turn on and off the heat, and a temperature set point, a switch to turn on and off the heat, and a
switch to turn on the fan override. switch to turn on the fan override.
[ [
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 = [initial-record, * follow-on-record] SenML-Pack = [ record, * record]
initial-record = initial-defined .and initial-generic
follow-on-record = follow-on-defined .and follow-on-generic
; first do a specification of the labels as defined:
initial-defined = { 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
follow-on-defined-group, ? n => tstr, ; Name
+ base-key-value-pair ? u => tstr, ; Units
? s => numeric, ; Value Sum
? t => numeric, ; Time
? ut => numeric, ; Update Time
? l => tstr, ; Link
? ( v => numeric // ; Numeric Value
vs => tstr // ; String Value
vb => bool // ; Boolean Value
vd => binary-value ) ; Data Value
* key-value-pair
} }
follow-on-defined-group = (
? n => tstr, ; Name
? u => tstr, ; Units
? s => numeric, ; Value Sum
? t => numeric, ; Time
? ut => numeric, ; Update Time
? l => tstr, ; Link
* key-value-pair,
? ( v => numeric // ; Numeric Value
vs => tstr // ; String Value
vb => bool // ; Boolean Value
vd => binary-value ) ; Data Value
)
follow-on-defined = { follow-on-defined-group }
; now define the generic versions ; now define the generic versions
key-value-pair = ( label => value )
initial-generic = { label = tstr .regexp "[A-Za-z0-9][-_:.A-Za-z0-9]*" / uint
follow-on-generic-group,
* base-key-value-pair,
}
follow-on-generic-group = (
+ key-value-pair,
)
follow-on-generic = { follow-on-generic-group }
key-value-pair = ( non-b-label => value )
base-key-value-pair = ( b-label => value )
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"
 End of changes. 24 change blocks. 
90 lines changed or deleted 66 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/