--- 1/draft-ietf-core-senml-11.txt 2017-12-14 06:13:51.646738195 -0800 +++ 2/draft-ietf-core-senml-12.txt 2017-12-14 06:13:51.734740272 -0800 @@ -1,24 +1,24 @@ Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track Z. Shelby -Expires: May 3, 2018 ARM +Expires: June 17, 2018 ARM J. Arkko A. Keranen Ericsson C. Bormann Universitaet Bremen TZI - October 30, 2017 + December 14, 2017 Media Types for Sensor Measurement Lists (SenML) - draft-ietf-core-senml-11 + draft-ietf-core-senml-12 Abstract 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 @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 3, 2018. + This Internet-Draft will expire on June 17, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,61 +58,62 @@ described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 6 - 4.3. Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 4.4. Resolved Records . . . . . . . . . . . . . . . . . . . . 9 - 4.5. Associating Meta-data . . . . . . . . . . . . . . . . . . 9 - 4.6. Configuration and Actuation usage . . . . . . . . . . . . 10 - 5. JSON Representation (application/senml+json) . . . . . . . . 10 - 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 11 - 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 11 - 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 12 - 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 13 - 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 14 - 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 14 + 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 4.5. Resolved Records . . . . . . . . . . . . . . . . . . . . 10 + 4.6. Associating Meta-data . . . . . . . . . . . . . . . . . . 10 + 4.7. Configuration and Actuation usage . . . . . . . . . . . . 10 + 5. JSON Representation (application/senml+json) . . . . . . . . 11 + 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 12 + 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 12 + 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 13 + 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 14 + 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 15 + 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 15 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 15 6. CBOR Representation (application/senml+cbor) . . . . . . . . 16 7. XML Representation (application/senml+xml) . . . . . . . . . 18 8. EXI Representation (application/senml+exi) . . . . . . . . . 20 9. Fragment Identification Methods . . . . . . . . . . . . . . . 23 9.1. Fragment Identification Examples . . . . . . . . . . . . 23 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 26 12.2. SenML Label Registry . . . . . . . . . . . . . . . . . . 30 12.3. Media Type Registration . . . . . . . . . . . . . . . . 31 - 12.3.1. senml+json Media Type Registration . . . . . . . . . 31 + 12.3.1. senml+json Media Type Registration . . . . . . . . . 32 12.3.2. sensml+json Media Type Registration . . . . . . . . 33 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 34 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 35 - 12.3.5. senml+xml Media Type Registration . . . . . . . . . 37 - 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 38 - 12.3.7. senml+exi Media Type Registration . . . . . . . . . 39 - 12.3.8. sensml+exi Media Type Registration . . . . . . . . . 41 - 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 42 - 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 42 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 - 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 - 16.2. Informative References . . . . . . . . . . . . . . . . . 45 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 + 12.3.5. senml+xml Media Type Registration . . . . . . . . . 36 + 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 37 + 12.3.7. senml+exi Media Type Registration . . . . . . . . . 38 + 12.3.8. sensml+exi Media Type Registration . . . . . . . . . 40 + 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 41 + 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 41 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 + 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 42 + 16.2. Informative References . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Overview 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 @@ -274,41 +275,74 @@ 4.2. Regular Fields Name: 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. - Unit: Units for a measurement value. Optional. + Unit: Unit for a measurement value. Optional. Value: Value of the entry. Optional if a Sum value is present, otherwise required. Values are represented using basic data types. This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value"). Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value 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 unit specified in the Unit value multiplied by seconds. Time: Time when value was recorded. Optional. Update Time: Period of time in seconds that represents the maximum time before this sensor will provide an updated reading for a measurement. Optional. This can be used to detect the failure of sensors or communications path from the sensor. -4.3. Considerations +4.3. SenML Labels + + Table 1 provides an overview of all SenML fields defined by this + document with their respective labels and data types. + + +---------------+-------+------------+------------+------------+ + | Name | Label | CBOR Label | JSON Type | XML Type | + +---------------+-------+------------+------------+------------+ + | Base Name | bn | -2 | String | string | + | Base Time | bt | -3 | Number | double | + | Base Unit | bu | -4 | String | string | + | Base Value | bv | -5 | Number | double | + | Base Sum | bs | -6 | Number | double | + | Version | bver | -1 | Number | int | + | Name | n | 0 | String | string | + | Unit | u | 1 | String | string | + | Value | v | 2 | Number | double | + | String Value | vs | 3 | String | string | + | Boolean Value | vb | 4 | Boolean | boolean | + | Data Value | vd | 8 | String (*) | string (*) | + | Value Sum | s | 5 | Number | double | + | Time | t | 6 | Number | double | + | Update Time | ut | 7 | Number | double | + +---------------+-------+------------+------------+------------+ + + Table 1: SenML Labels + + Data Value is base64 encoded string with URL safe alphabet as defined + in Section 5 of [RFC4648], with padding omitted. + + For details of the JSON representation see Section 5, for the CBOR + Section 6, and for the XML Section 7. + +4.4. Considerations The SenML format can be extended with further custom fields. Both new base and regular fields are allowed. See Section 12.2 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. 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 Record in the Pack. @@ -380,21 +414,21 @@ 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.5. Resolved Records Sometimes it is useful to be able to refer to a defined normalized format for SenML records. This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values, i.e., labels starting with the character 'b', except for Version fields (see below), and has no relative times. To resolve the records, the base values of the SenML Pack (if any) are @@ -404,48 +438,48 @@ 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 the field is resolved. -4.5. Associating Meta-data +4.6. Associating Meta-data 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]). -4.6. Configuration and Actuation usage +4.7. Configuration and Actuation usage SenML can also be used for configuring parameters and controlling 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 interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as 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) - For the SenML fields shown in Table 1, the SenML labels are used as + For the SenML fields shown in Table 2, the SenML labels are used as the JSON object member names within JSON objects representing the JSON SenML Records. +---------------+-------+---------+ | Name | label | Type | +---------------+-------+---------+ | Base Name | bn | String | | Base Time | bt | Number | | Base Unit | bu | String | | Base Value | bv | Number | @@ -455,21 +489,21 @@ | Unit | u | String | | Value | v | Number | | String Value | vs | String | | Boolean Value | vb | Boolean | | Data Value | vd | String | | Value Sum | s | Number | | Time | t | Number | | Update Time | ut | Number | +---------------+-------+---------+ - Table 1: JSON SenML Labels + Table 2: JSON SenML Labels 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. @@ -582,21 +617,21 @@ +----------+------+-----------------+ | Encoding | Size | Compressed Size | +----------+------+-----------------+ | JSON | 573 | 206 | | XML | 649 | 235 | | CBOR | 254 | 196 | | EXI | 161 | 184 | +----------+------+-----------------+ - Table 2: Size Comparisons + Table 3: Size Comparisons 5.1.4. Resolved Data The following shows the example from the previous section show in resolved format. [ {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, "v":20}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, @@ -716,47 +750,47 @@ a representation SHOULD be chosen such that when the CBOR value is converted back to an IEEE double precision floating point value, it has exactly the same value as the original Number. For the version number, only an unsigned integer is allowed. o Characters in the String Value are encoded using a definite length text string (type 3). Octets in the Data Value are encoded using a definite length byte string (type 2). o For compactness, the CBOR representation uses integers for the - labels, as defined in Table 3. This table is conclusive, i.e., + labels, as defined in Table 4. This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys. This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. +---------------+-------+------------+ | Name | Label | CBOR Label | +---------------+-------+------------+ | Version | bver | -1 | | Base Name | bn | -2 | | Base Time | bt | -3 | - | Base Units | bu | -4 | + | Base Unit | bu | -4 | | Base Value | bv | -5 | | Base Sum | bs | -6 | | Name | n | 0 | - | Units | u | 1 | + | Unit | u | 1 | | Value | v | 2 | | String Value | vs | 3 | | Boolean Value | vb | 4 | | Value Sum | s | 5 | | Time | t | 6 | | Update Time | ut | 7 | | Data Value | vd | 8 | +---------------+-------+------------+ - Table 3: CBOR representation: integers for map keys + Table 4: CBOR representation: integers for map keys o For streaming SensML in CBOR representation, the array containing the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. The following example shows a dump of the CBOR example for the same sensor measurement as in Section 5.1.2. 0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:| 0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3a |10e2073a0108006:| @@ -824,21 +858,21 @@ | Unit | u | string | | Value | v | double | | String Value | vs | string | | Data Value | vd | string | | Boolean Value | vb | boolean | | Value Sum | s | double | | Time | t | double | | Update Time | ut | double | +---------------+-------+---------+ - Table 4: XML SenML Labels + Table 5: XML SenML Labels The RelaxNG schema for the XML is: default namespace = "urn:ietf:params:xml:ns:senml" namespace rng = "http://relaxng.org/ns/structure/1.0" senml = element senml { attribute bn { xsd:string }?, attribute bt { xsd:double }?, attribute bv { xsd:double }?, @@ -1027,22 +1061,22 @@ as well as the an integrated sum. For many types of measurements, the sum is more useful than the current value. For example, an electrical meter that measures the energy a given computer uses will typically want to measure the cumulative amount of energy used. This is less prone to error than reporting the power each second and trying to have something on the server side sum together all the power measurements. If the network between the sensor and the meter goes down over some period of time, when it comes back up, the cumulative sum helps reflect what happened while the network was 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 "s" field of the measurement. It might optionally include the + the unit set to watts, but it would put the sum of energy used in the + "s" field of the measurement. It might optionally include the current power in the "v" field. While the benefit of using the integrated sum is fairly clear for measurements like power and energy, it is less obvious for something like temperature. Reporting the sum of the temperature makes it easy to compute averages even when the individual temperature values are not reported frequently enough to compute accurate averages. Implementers are encouraged to report the cumulative sum as well as the raw value of a given sensor. @@ -1080,21 +1114,20 @@ ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base Value ? bs => numeric, ; Base Sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? 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 } ; now define the generic versions key-value-pair = ( label => value ) @@ -1107,34 +1140,34 @@ Figure 1: Common CDDL specification for CBOR and JSON SenML For JSON, we use text labels and base64url-encoded binary data (Figure 2). bver = "bver" n = "n" s = "s" bn = "bn" u = "u" t = "t" bt = "bt" v = "v" ut = "ut" bu = "bu" vs = "vs" vd = "vd" - bv = "bv" vb = "vb" l = "l" + bv = "bv" vb = "vb" bs = "bs" binary-value = tstr ; base64url encoded Figure 2: JSON-specific CDDL specification for SenML For CBOR, we use integer labels and native binary data (Figure 3). bver = -1 n = 0 s = 5 bn = -2 u = 1 t = 6 bt = -3 v = 2 ut = 7 bu = -4 vs = 3 vd = 8 - bv = -5 vb = 4 l = 9 + bv = -5 vb = 4 bs = -6 binary-value = bstr Figure 3: CBOR-specific CDDL specification for SenML 12. IANA Considerations Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification. @@ -1216,41 +1249,41 @@ | | level) | | | | 1/s | 1 per second (event rate) | 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 | | | per minute)* | | | | beats | 1 (Cumulative number of heart | float | RFC-AAAA | | | beats)* | | | | S/m | Siemens per meter (conductivity) | float | RFC-AAAA | +----------+------------------------------------+-------+-----------+ - Table 5 + Table 6 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 unit is "/". For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! New entries can be added to the registration by Expert Review as defined in [RFC8126]. 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 be added. - 2. Units should define the semantic information and be chosen - carefully. implementers need to remember that the same word may + 2. Each unit should define the semantic information and be chosen + carefully. Implementers need to remember that the same word may be used in different real-life contexts. For example, degrees when measuring latitude have no semantic relation to degrees when measuring temperature; thus two different units are needed. 3. These measurements are produced by computers for consumption by computers. The principle is that conversion has to be easily be done when both reading and writing the media type. The value of a single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. @@ -1304,65 +1337,71 @@ name. 11. A good list of common units can be found in the Unified Code for Units of Measure [UCUM]. 12.2. SenML Label Registry IANA will create a new registry for SenML labels. The initial content of the registry is: - +---------------+-------+------+---------+--------+---------+ - | Name | Label | CBOR | Type | EXI ID | Note | - +---------------+-------+------+---------+--------+---------+ - | Base Name | bn | -2 | string | a | RFCXXXX | - | Base Sum | bs | -6 | double | a | RFCXXXX | - | Base Time | bt | -3 | double | a | RFCXXXX | - | Base Unit | bu | -4 | string | a | RFCXXXX | - | Base Value | bv | -5 | double | a | RFCXXXX | - | Base Version | bver | -1 | int | a | RFCXXXX | - | Boolean Value | vb | 4 | boolean | a | RFCXXXX | - | Data Value | vd | 8 | string | a | RFCXXXX | - | Name | n | 0 | string | a | RFCXXXX | - | String Value | vs | 3 | string | a | RFCXXXX | - | Time | t | 6 | double | a | RFCXXXX | - | Unit | u | 1 | string | a | RFCXXXX | - | Update Time | ut | 7 | double | a | RFCXXXX | - | Value | v | 2 | double | a | RFCXXXX | - | Value Sum | s | 5 | double | a | RFCXXXX | - +---------------+-------+------+---------+--------+---------+ + +--------------+-------+----+-----------+----------+----+-----------+ + | Name | Label | CL | JSON Type | XML Type | EI | Reference | + +--------------+-------+----+-----------+----------+----+-----------+ + | Base Name | bn | -2 | String | string | a | RFCXXXX | + | Base Time | bt | -3 | Number | double | a | RFCXXXX | + | Base Unit | bu | -4 | String | string | a | RFCXXXX | + | Base Value | bv | -5 | Number | double | a | RFCXXXX | + | Base Sum | bs | -6 | Number | double | a | RFCXXXX | + | Base Version | bver | -1 | Number | int | a | RFCXXXX | + | Name | n | 0 | String | string | a | RFCXXXX | + | Unit | u | 1 | String | string | a | RFCXXXX | + | Value | v | 2 | Number | double | a | RFCXXXX | + | String Value | vs | 3 | String | string | a | RFCXXXX | + | Boolean | vb | 4 | Boolean | boolean | a | RFCXXXX | + | Value | | | | | | | + | Data Value | vd | 8 | String | string | a | RFCXXXX | + | Value Sum | s | 5 | Number | double | a | RFCXXXX | + | Time | t | 6 | Number | double | a | RFCXXXX | + | Update Time | ut | 7 | Number | double | a | RFCXXXX | + +--------------+-------+----+-----------+----------+----+-----------+ - Table 6: SenML Labels + Table 7: IANA Registry for SenML Labels, CL = CBOR Label, EI = EXI ID + + This is the same table as Table 1, with notes removed, and with + columns added for the information that is all the same for this + initial set of registrations, but will need to be supplied with a + different value for new registrations. Note to RFC Editor. Please replace RFCXXXX with the number for this RFC. 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 - encoding for any new labels. The EXI ID column contains the EXI - schemaId value of the first Schema which includes this label or is - empty if this label was not intended for use with EXI. The Note - field SHOULD contain information about where to find out more - information about this label. + encoding for any new labels. The EI column contains the EXI schemaId + value of the first Schema which includes this label or is empty if + this label was not intended for use with EXI. The Note field SHOULD + contain information about where to find out more information about + this label. 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 Number. XML boolean and string become a JSON Boolean and String respectively. CBOR represents numeric values with a CBOR type that does not lose any information from the JSON value. EXI uses the XML types. - New entries can be added to the registration by either Expert Review - or IESG Approval as defined in [RFC8126]. Experts should exercise - their own good judgment but need to consider that shorter labels - should have more strict review. New entries should not be made that - counteract the advice at the end of Section 4.3. + New entries can be added to the registration by Expert Review as + defined in [RFC8126]. Experts should exercise their own good + judgment but need to consider that shorter labels should have more + strict review. New entries should not be made that counteract the + advice at the end of Section 4.4. All new SenML labels that have "base" semantics (see Section 4.1) MUST start with the character 'b'. Regular labels MUST NOT start with that character. 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 registry. Extensions that add a label that is intended for use with EXI need to @@ -1379,21 +1418,22 @@ 12.3. Media Type Registration 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. Note to RFC Editor - please remove this paragraph. Note that a request for media type review for senml+json was sent to the media- types@iana.org on Sept 21, 2010. A second request for all the types - was sent on October 31, 2016. + was sent on October 31, 2016. Please change all instances of RFC- + AAAA with the RFC number of this document. 12.3.1. senml+json Media Type Registration Type name: application Subtype name: senml+json Required parameters: none Optional parameters: none @@ -1390,35 +1430,28 @@ 12.3.1. senml+json Media Type Registration Type name: application Subtype name: senml+json Required parameters: none Optional parameters: none + Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC7159]. See RFC-AAAA for details. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems @@ -1462,29 +1495,21 @@ Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC7159]. See RFC-AAAA for details. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems @@ -1521,29 +1546,21 @@ Subtype name: senml+cbor Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [RFC7049]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. Interoperability considerations: Applications should ignore any key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the CBOR object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems @@ -1579,32 +1596,25 @@ 12.3.4. sensml+cbor Media Type Registration Type name: application Subtype name: sensml+cbor Required parameters: none Optional parameters: none + Encoding considerations: Must be encoded as using [RFC7049]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. Interoperability considerations: Applications should ignore any key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the CBOR object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems @@ -1641,29 +1651,21 @@ Subtype name: senml+xml Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. 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. Published specification: RFC-AAAA @@ -1705,38 +1708,31 @@ Subtype name: sensml+xml Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. 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. Published specification: RFC-AAAA + Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Fragment identifier considerations: Fragment identification for application/senml+xml is supported by using fragment identifiers as specified by RFC-AAAA. Additional information: @@ -1760,33 +1756,24 @@ 12.3.7. senml+exi Media Type Registration Type name: application Subtype name: senml+exi Required parameters: none Optional parameters: none - Encoding considerations: Must be encoded as using [W3C.REC-exi-20140211]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. 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. Further information on using schemas to guide the EXI can be found in RFC-AAAA. Published specification: RFC-AAAA @@ -1828,29 +1815,21 @@ Subtype name: sensml+exi Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-exi-20140211]. See RFC-AAAA for details. - Security considerations: Sensor data can contain a wide range of - information ranging from information that is very public, such the - outside temperature in a given city, to very private information that - requires integrity and confidentiality protection, such as patient - health information. This format does not provide any security and - instead relies on the transport protocol that carries it to provide - security. Given applications need to look at the overall context of - how this media type will be used to decide if the security is - adequate. + Security considerations: See Section 13 of RFC-AAAA. 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. Further information on using schemas to guide the EXI can be found in RFC-AAAA. Published specification: RFC-AAAA @@ -1891,41 +1870,49 @@ Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces 12.5. CoAP Content-Format Registration IANA is requested to assign CoAP Content-Format IDs for the SenML media types in the "CoAP Content-Formats" sub-registry, within the "CoRE Parameters" registry [RFC7252]. All IDs are assigned from the - "Expert Review" (0-255) range. The assigned IDs are show in Table 7. + "Expert Review" (0-255) range. The assigned IDs are show in Table 8. +-------------------------+-----+ | Media type | ID | +-------------------------+-----+ | application/senml+json | TBD | | application/sensml+json | TBD | | application/senml+cbor | TBD | | application/sensml+cbor | TBD | | application/senml+xml | TBD | | application/sensml+xml | TBD | | application/senml+exi | TBD | | application/sensml+exi | TBD | +-------------------------+-----+ - Table 7: CoAP Content-Format IDs + Table 8: CoAP Content-Format IDs 13. Security Considerations - See Section 14. Further discussion of security properties can be - found in Section 12.3. + 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. + + See also Section 14. 14. Privacy Considerations 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.