Draft: draft-ietf-core-senml

Commentary: s / field / attribute/ where appropriate . Add appropriate note on the usage . Fix up some of the  and XML text as well . 
 Look good to me 
  voting for field .
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 attributes 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 RFC7159, CBOR RFC7049, XML, and Efficient XML
Interchange (EXI) W3C.REC-exi-20140211.
The basic design is an array with a series of measurements.  The
following example shows two measurements made at different times.
The value of a measurement is given by the "v" attribute, the time of
a measurement is in the "t" attribute, the "n" attribute has a unique
sensor name, and the unit of the measurement is carried in the "u"
attribute.
To keep the messages small, it does not make sense to repeat the "n"
attribute in each SenML Record so there is a concept of a Base Name
which is simply a string that is prepended to the Name field of all
elements in that record and any records that follow it.  So a more
compact form of the example above is the following.
In the above example the Base Name is in the "bn" attribute and the
"n" attributes in each Record are the empty string so they are
omitted.
The basic design is an array with a series of measurements.  The
following example shows two measurements made at different times.
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
name, and the unit of the measurement is carried in the "u" field.
To keep the messages small, it does not make sense to repeat the "n"
field in each SenML Record so there is a concept of a Base Name which
is simply a string that is prepended to the Name field of all
elements in that record and any records that follow it.  So a more
compact form of the example above is the following.
In the above example the Base Name is in the "bn" field and the "n"
fields in each Record are the empty string so they are omitted.
A short name used in SenML Records to denote different SenML
attributes (e.g., "v" for "value").
Each SenML Pack carries a single array that represents a set of
measurements and/or parameters.  This array contains a series of
SenML Records with several attributes described below.  There are two
kind of attributes: base and regular.  The base attributes can be
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
to, but not including, the next Record that has that same base
attribute.  All base attributes are optional.  Regular attributes can
be included in any SenML Record and apply only to that Record.
A short name used in SenML Records to denote different SenML
fields (e.g., "v" for "value").
A component of a record that associates a value to a SenML Label
for this record.
This document uses the terms "attribute" and "tag" where they occur
with the underlying technologies (XML, CBOR RFC7049, and Link Format
RFC6690), not for SenML concepts per se.  Note that "attribute" has
been widely used previously as a synonym for SenML "field", though.
Each SenML Pack carries a single array that represents a set of
measurements and/or parameters.  This array contains a series of
SenML Records with several fields described below.  There are two
kinds of fields: base and regular.  The base fields can be included
in any SenML Record and they apply to the entries in the Record.
Each base field also applies to all Records after it up to, but not
including, the next Record that has that same base field.  All base
fields are optional.  Regular fields can be included in any SenML
Record and apply only to that Record.
Name of the sensor or parameter.  When appended to the Base Name
attribute, this must result in a globally unique identifier for
the resource.  The name is optional, if the Base Name is present.
If the name is missing, Base Name must uniquely identify the
resource.  This can be used to represent a large array of
measurements from the same sensor without having to repeat its
identifier on every measurement.
Name of the sensor or parameter.  When appended to the Base Name
field, this must result in a globally unique identifier for the
resource.  The name is optional, if the Base Name is present.  If
the name is missing, Base Name must uniquely identify the
resource.  This can be used to represent a large array of
measurements from the same sensor without having to repeat its
identifier on every measurement.
Integrated sum of the values over time.  Optional.  This attribute
is in the units specified in the Unit value multiplied by seconds.
Integrated sum of the values over time.  Optional.  This field is
in the units specified in the Unit value multiplied by seconds.
The SenML format can be extended with further custom attributes.
Both new base and regular attributes are allowed.  See iana-senml-
label-registry for details.  Implementations MUST ignore attributes
they don't recognize unless that attribute has a label name that ends
with the '_' character in which case an error MUST be generated.
Systems reading one of the objects MUST check for 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.
This allows the version number to indicate that the object contains
mandatory to understand attributes.  New version numbers can only be
defined in an RFC that updates this specification or it successors.
The SenML format can be extended with further custom fields.  Both
new base and regular fields are allowed.  See iana-senml-label-
registry for details.  Implementations MUST ignore fields they don't
recognize unless that field has a label name that ends with the '_'
character in which case an error MUST be generated.
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
system understands, the system SHOULD NOT use this object.  This
allows the version number to indicate that the object contains
mandatory to understand fields.  New version numbers can only be
defined in an RFC that updates this specification or it successors.
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
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 and the measurement was made roughly "now".  A negative value is
used to indicate seconds in the past from roughly "now".  A positive
value is used to indicate the number of seconds, excluding leap
seconds, since the start of the year 1970 in UTC.
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
Sum values are added together to get the sum of measurement.  If
neither the Base Sum or Sum are present, then the measurement does
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
accuracy, can be very complex.  Future specification may add new
attributes to provide better information about the statistical
properties of the measurement.
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
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
measurement was made roughly "now".  A negative value is used to
indicate seconds in the past from roughly "now".  A positive value is
used to indicate the number of seconds, excluding leap seconds, since
the start of the year 1970 in UTC.
If only one of the Base Sum or Sum value is present, the missing
field is considered to have a value of zero.  The Base Sum and Sum
values are added together to get the sum of measurement.  If neither
the Base Sum or Sum are present, then the measurement does not have a
sum value.
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
added together to get the value of the measurement.
Representing the statistical characteristics of measurements, such as
accuracy, can be very complex.  Future specification may add new
fields to provide better information about the statistical properties
of the measurement.
Future specification that defines new base attributes need to specify
how the attribute is resolved.
Future specification that defines new base fields need to specify how
the field is resolved.
SenML is designed to carry the minimum dynamic information about
measurements, and for efficiency reasons does not carry significant
static meta-data about the device, object or sensors.  Instead, it is
assumed that this meta-data is carried out of band.  For web
resources using SenML Packs, this meta-data can be made available
using the CoRE Link Format RFC6690.  The most obvious use of this
link format is to describe that a resource is available in a SenML
format in the first place.  The relevant media type indicator is
included in the Content-Type (ct=) attribute.
SenML is designed to carry the minimum dynamic information about
measurements, and for efficiency reasons does not carry significant
static meta-data about the device, object or sensors.  Instead, it is
assumed that this meta-data is carried out of band.  For web
resources using SenML Packs, this meta-data can be made available
using the CoRE Link Format RFC6690.  The most obvious use of this
link format is to describe that a resource is available in a SenML
format in the first place.  The relevant media type indicator is
included in the Content-Type (ct=) link attribute (which is defined
for the Link Format in Section 7.2.1 of RFC7252).
The SenML labels (JSON object member names) shown in tbl-json-labels
are used in JSON SenML Record attributes.
The root content consists of an array with one JSON object for each
SenML Record.  All the fields in the above table MAY occur in the
records with the type specified in the table.
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.
For the SenML fields shown in tbl-json-labels, the SenML labels are
used as the JSON object member names within are used in JSON SenML
Records represented as these JSON objects.
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
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
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.
The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record.  The SenML attributes are
represented as XML attributes.  The following table shows the mapping
of the SenML labels, which are used for the attribute name, to the
attribute types used in the XML senml tags.
The SenML Stream is represented as a sensml element that contains a
series of senml elements for each SenML Record.  The SenML fields are
represented as XML attributes.  For each field defined in this
document, the following table shows the SenML labels, which are used
for the XML attribute name, as well as the according restrictions on
the XML attribute values ("type") as used in the XML senml elements.
the "s" attribute of the measurement.  It might optionally include
the current power in the "v" attribute.
the "s" field of the measurement.  It might optionally include the
current power in the "v" field.
Interoperability considerations: Applications should ignore any XML
tags or attributes that they do not understand.  This allows
backwards compatibility extensions to this specification.  The "bver"
attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of
the XML.
Interoperability considerations: Applications should ignore any
XMLtags or attributes that they do not understand.  This allows
backwards compatibility extensions to this specification.  The "bver"
attribute in the senml XML tag can be used to ensure the receiver
supports a minimal level of functionality needed by the creator of
the XML.