Draft: draft-ietf-core-senml

Commentary: This all looks fine . Sorry it too so long . When I first looked at the diff it looked extensive but when I got a better diff tool I realized the changes are mostly minor .
This specification defines media types for representing simple sensor
measurements and device parameters in the Sensor Measurement Lists
(SenML).  Representations are defined in JavaScript Object Notation
(JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model.  A simple sensor, such as a
temperature sensor, could use this media type in protocols such as
HTTP or CoAP to transport the measurements of the sensor or to be
configured.
Connecting sensors to the Internet is not new, and there have been
many protocols designed to facilitate it.  This specification defines
new media types for carrying simple sensor information in a protocol
such as HTTP or CoAP.  This format was designed so that processors
with very limited capabilities could easily encode a sensor
measurement into the media type, while at the same time a server
parsing the data could relatively efficiently collect a large number
of sensor measurements.  SenML can be used for a variety of data flow
models, most notably data feeds pushed from a sensor to a collector,
and the web resource model where the sensor is requested as a
resource representation (e.g., "GET /sensor/temperature").
This specification defines media types for representing simple sensor
measurements and device parameters in the Sensor Measurement Lists
(SenML).  Representations are defined in JavaScript Object Notation
(JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model.  A simple sensor, such as a
temperature sensor, could use one of these media types in protocols
such as HTTP or CoAP to transport the measurements of the sensor or
to be configured.
Connecting sensors to the Internet is not new, and there have been
many protocols designed to facilitate it.  This specification defines
new media types for carrying simple sensor information in a protocol
such as HTTP RFC7230 or CoAP RFC7252.  This format was designed so
that processors with very limited capabilities could easily encode a
sensor measurement into the media type, while at the same time a
server parsing the data could relatively efficiently collect a large
number of sensor measurements.  SenML can be used for a variety of
data flow models, most notably data feeds pushed from a sensor to a
collector, and the web resource model where the sensor is requested
as a resource representation (e.g., "GET /sensor/temperature").
SenML is defined by a data model for measurements and simple meta-
data about measurements and devices.  The data is structured as a
single array that contains a series of SenML Records which can each
contain fields such as an unique identifier for the sensor, the time
the measurement was made, the unit the measurement is in, and the
current value of the sensor.  Serializations for this data model are
defined for JSON RFC7159, CBOR RFC7049, XML, and Efficient XML
Interchange (EXI) W3C.REC-exi-20140211.
SenML is defined by a data model for measurements and simple meta-
data about measurements and devices.  The data is structured as a
single array that contains a series of SenML Records which can each
contain fields such as an unique identifier for the sensor, the time
the measurement was made, the unit the measurement is in, and the
current value of the sensor.  Serializations for this data model are
defined for JSON RFC8259, CBOR RFC7049, XML W3C.REC-xml-20081126, and
Efficient XML Interchange (EXI) W3C.REC-exi-20140211.
Some devices have accurate time while others do not so SenML supports
absolute and relative times.  Time is represented in floating point
as seconds and values greater than zero represent an absolute time
relative to the Unix epoch while values of 0 or less represent a
relative time in the past from the current time.  A simple sensor
with no absolute wall clock time might take a measurement every
second, batch up 60 of them, and then send the batch to a server.  It
would include the relative time each measurement was made compared to
the time the batch was sent in each SenML Record.  The server might
have accurate NTP time and use the time it received the data, and the
relative offset, to replace the times in the SenML with absolute
times before saving the SenML Pack in a document database.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC2119.
Some devices have accurate time while others do not so SenML supports
absolute and relative times.  Time is represented in floating point
as seconds.  Values greater than zero represent an absolute time
relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the
time is counted same way as the Portable Operating System Interface
(POSIX) "seconds since the epoch" TIME_T.  Values of 0 or less
represent a relative time in the past from the current time.  A
simple sensor with no absolute wall clock time might take a
measurement every second, batch up 60 of them, and then send the
batch to a server.  It would include the relative time each
measurement was made compared to the time the batch was sent in each
SenML Record.  The server might have accurate NTP time and use the
time it received the data, and the relative offset, to replace the
times in the SenML with absolute times before saving the SenML Pack
in a document database.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
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.
of many URI schemes, such as the 'tag' scheme RFC4151 and the 'ni'
scheme RFC6920, in names as such.  The use of URIs with characters
incompatible with this set, and possible mapping rules between the
two, are outside of the scope of the present document.
Only the UTF-8 form of JSON is allowed.  Characters in the String
Value are encoded using the escape sequences defined in RFC7159.
Octets in the Data Value are base64 encoded with URL safe alphabet as
defined in Section 5 of RFC4648, with padding omitted.
Systems receiving measurements MUST be able to process the range of
floating point numbers that are representable as an IEEE double
precision floating point numbers IEEE.754.1985.  The number of
significant digits in any measurement is not relevant, so a reading
of 1.1 has exactly the same semantic meaning as 1.10.  If the value
has an exponent, the "e" MUST be in lower case.  The mantissa SHOULD
be less than 19 characters long and the exponent SHOULD be less than
5 characters long.  This allows time values to have better than micro
second precision over the next 100 years.
Only the UTF-8 RFC3629 form of JSON is allowed.  Characters in the
String Value are encoded using the escape sequences defined in
RFC8259.  Octets in the Data Value are base64 encoded with URL safe
alphabet as defined in Section 5 of RFC4648, with padding omitted.
Systems receiving measurements MUST be able to process the range of
floating point numbers that are representable as an IEEE double
precision floating point numbers IEEE.754.1985.  This allows time
values to have better than microsecond precision over the next 100
years.  The number of significant digits in any measurement is not
relevant, so a reading of 1.1 has exactly the same semantic meaning
as 1.10.  If the value has an exponent, the "e" MUST be in lower
case.  In the interest of avoiding unnecessary verbosity and speeding
up processing, the mantissa SHOULD be less than 19 characters long
and the exponent SHOULD be less than 5 characters long.
Note that in some usage scenarios of SenML the implementations MAY
store or transmit SenML in a stream-like fashion, where data is
collected over time and continuously added to the object.  This mode
of operation is optional, but systems or protocols using SenML in
this fashion MUST specify that they are doing this.  SenML defines a
separate media type to indicate Sensor Streaming Measurement Lists
(SensML) for this usage (see sec-sensml-json).  In this situation the
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
and not have to wait for the full SensML Stream to be complete.
Note that in some usage scenarios of SenML the implementations MAY
store or transmit SenML in a stream-like fashion, where data is
collected over time and continuously added to the object.  This mode
of operation is optional, but systems or protocols using SenML in
this fashion MUST specify that they are doing this.  SenML defines
separate media types to indicate Sensor Streaming Measurement Lists
(SensML) for this usage (see sec-sensml-json).  In this situation the
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
and not have to wait for the full SensML Stream to be complete.
Only the UTF-8 form of XML is allowed.  Characters in the String
Value are encoded using the escape sequences defined in RFC7159.
Octets in the Data Value are base64 encoded with URL safe alphabet as
defined in Section 5 of RFC4648.
Only the UTF-8 form of XML is allowed.  Characters in the String
Value are encoded using the escape sequences defined in RFC8259.
Octets in the Data Value are base64 encoded with URL safe alphabet as
defined in Section 5 of RFC4648.
For efficient transmission of SenML over e.g. a constrained network,
Efficient XML Interchange (EXI) can be used.  This encodes the XML
Schema structure of SenML into binary tags and values rather than
ASCII text.  An EXI representation of SenML SHOULD be made using the
strict schema-mode of EXI.  This mode however does not allow tag
extensions to the schema, and therefore any extensions will be lost
in the encoding.  For uses where extensions need to be preserved in
EXI, the non-strict schema mode of EXI MAY be used.
For efficient transmission of SenML over e.g. a constrained network,
Efficient XML Interchange (EXI) can be used.  This encodes the XML
Schema W3C.REC-xmlschema-1-20041028 structure of SenML into binary
tags and values rather than ASCII text.  An EXI representation of
SenML SHOULD be made using the strict schema-mode of EXI.  This mode
however does not allow tag extensions to the schema, and therefore
any extensions will be lost in the encoding.  For uses where
extensions need to be preserved in EXI, the non-strict schema mode of
EXI MAY be used.
For reference, the JSON and CBOR representations can be described
with the common CDDL I-D.ietf-cbor-cddl specification in senmlcddl.
As a convenient reference, the JSON and CBOR representations can be
described with the common CDDL I-D.ietf-cbor-cddl specification in
senmlcddl (informative).
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.  Clipboard formats are defined for
the JSON and XML form of lists but do not make sense for streams or
other formats.
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.  This document registers media
types for each serialization format of SenML (JSON, CBOR, and EXI)
and also media types for the same formats of the streaming use
(SensML).  Clipboard formats are defined for the JSON and XML form of
lists but do not make sense for streams or other formats.
Sensor data can contain a wide range of information ranging from
information that is very public, such as the outside temperature in a
given city, to very private information that requires integrity and
confidentiality protection, such as patient health information.  The
SenML format does not provide any security and instead relies on the
protocol that carries it to provide security.  Applications using
SenML need to look at the overall context of how this media type will
be used to decide if the security is adequate.
Sensor data can contain a wide range of information ranging from
information that is very public, such as the outside temperature in a
given city, to very private information that requires integrity and
confidentiality protection, such as patient health information.  The
SenML formats do not provide any security and instead rely on the
protocol that carries them to provide security.  Applications using
SenML need to look at the overall context of how these media types
will be used to decide if the security is adequate.  The SenML
formats defined by this specification do not contain any executable
content.  However, future extensions could potentially embed
application specific executable content in the data.
Sensor data can range from information with almost no security
considerations, such as the current temperature in a given city, to
highly sensitive medical or location data.  This specification
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
with TLS that can provide integrity, confidentiality, and
authentication information about the source of the data.
Sensor data can range from information with almost no security
considerations, such as the current temperature in a given city, to
highly sensitive medical or location data.  This specification
provides no security protection for the data but is meant to be used
inside another container or transport protocol such as S/MIME RFC5751
or HTTP with TLS RFC5246 that can provide integrity, confidentiality,
and authentication information about the source of the data.