draft-ietf-core-senml-01.txt   draft-ietf-core-senml-02.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track Z. Shelby Intended status: Standards Track Z. Shelby
Expires: January 9, 2017 ARM Expires: January 9, 2017 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
July 8, 2016 July 8, 2016
Media Types for Sensor Markup Language (SenML) Media Types for Sensor Markup Language (SenML)
draft-ietf-core-senml-01 draft-ietf-core-senml-02
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 Markup Language measurements and device parameters in the Sensor Markup Language
(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 2, line 43 skipping to change at page 2, line 43
5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 9 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 9
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 11 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 11
5.1.4. Collection of Resources . . . . . . . . . . . . . . . 12 5.1.4. Collection of Resources . . . . . . . . . . . . . . . 12
6. CBOR Representation (application/senml+cbor) . . . . . . . . 12 6. CBOR Representation (application/senml+cbor) . . . . . . . . 12
7. XML Representation (application/senml+xml) . . . . . . . . . 13 7. XML Representation (application/senml+xml) . . . . . . . . . 13
8. EXI Representation (application/senml-exi) . . . . . . . . . 15 8. EXI Representation (application/senml-exi) . . . . . . . . . 15
9. Usage Considerations . . . . . . . . . . . . . . . . . . . . 17 9. Usage Considerations . . . . . . . . . . . . . . . . . . . . 17
10. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 20 11.1. Units Registry . . . . . . . . . . . . . . . . . . . . . 20
11.2. SenML label registry . . . . . . . . . . . . . . . . . . 23 11.2. SenML label registry . . . . . . . . . . . . . . . . . . 24
11.3. Media Type Registration . . . . . . . . . . . . . . . . 24 11.3. Media Type Registration . . . . . . . . . . . . . . . . 24
11.3.1. senml+json Media Type Registration . . . . . . . . . 24 11.3.1. senml+json Media Type Registration . . . . . . . . . 24
11.3.2. senml+cbor Media Type Registration . . . . . . . . . 25 11.3.2. senml+cbor Media Type Registration . . . . . . . . . 25
11.3.3. senml+xml Media Type Registration . . . . . . . . . 26 11.3.3. senml+xml Media Type Registration . . . . . . . . . 26
11.3.4. senml-exi Media Type Registration . . . . . . . . . 27 11.3.4. senml-exi Media Type Registration . . . . . . . . . 27
11.4. XML Namespace Registration . . . . . . . . . . . . . . . 28 11.4. XML Namespace Registration . . . . . . . . . . . . . . . 28
11.5. CoAP Content-Format Registration . . . . . . . . . . . . 28 11.5. CoAP Content-Format Registration . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 5, line 48 skipping to change at page 5, line 48
Record. 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,
then the base unit is used. Otherwise the value of found in the then the Base Unit is used. Otherwise the value found in the Unit
Unit is used. (if any) is used.
Base Value: A base value is added to the value found in an entry, Base Value: A base value is added to the value found in an entry,
similar to Base Time. similar to Base Time.
Version: Version number of media type format. This attribute is an Version: Version number of media type format. This attribute is an
optional positive integer and defaults to 5 if not present. [RFC optional positive integer and defaults to 5 if not present. [RFC
Editor: change the default value to 10 when this specification is Editor: change the default value to 10 when this specification is
published as an RFC and remove this note] published as an RFC and remove this note]
4.2. Regular attributes 4.2. Regular attributes
skipping to change at page 13, line 29 skipping to change at page 13, line 29
| Time | t | 6 | | Time | t | 6 |
| Update Time | ut | 7 | | Update Time | ut | 7 |
| Data Value | vd | 8 | | Data Value | vd | 8 |
+---------------+------------+------------+ +---------------+------------+------------+
Table 3: CBOR representation: integers for map keys Table 3: CBOR representation: integers for map keys
The following example shows a dump of the CBOR example for the same The following example shows a dump of the CBOR example for the same
sensor measurement as in Section 5.1.2. sensor measurement as in Section 5.1.2.
0000 87 a7 21 78 1c 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 33 |10e2073a01080063|
0020 2f 22 fb 41 d3 03 a1 5b 00 10 62 23 61 41 20 05 |/".A...[..b#aA .|
0030 00 67 76 6f 6c 74 61 67 65 01 61 56 02 fb 40 5e |.gvoltage.aV..@^|
0040 06 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 |.fffff..gcurrent|
0050 06 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 |.$..?.333333..gc|
0060 75 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc |urrent.#..?.....|
0070 cc cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb |....gcurrent."..|
0080 3f f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 |?.ffffff..gcurre|
0090 6e 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 |nt.!..>...gcurre|
00a0 6e 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 |nt. ..?.........|
00b0 67 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 |gcurrent....?.33|
00c0 33 33 33 33 |3333|
00c4
7. XML Representation (application/senml+xml) 7. XML Representation (application/senml+xml)
A SenML Pack or Stream can also be represented in XML format as A SenML Pack or Stream can also be represented in XML format as
defined in this section. The following example shows an XML example defined in this section. The following example shows an XML example
for the same sensor measurement as in Section 5.1.2. for the same sensor measurement as in Section 5.1.2.
<sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml bn="urn:dev:ow:10e2073a01080063/" bt="1.276020076001e+09"
bu="A" bver="5" n="voltage" u="V" v="120.1"></senml>
<senml n="current" t="-5" v="1.2"></senml>
<senml n="current" t="-4" v="1.3"></senml>
<senml n="current" t="-3" v="1.4"></senml>
<senml n="current" t="-2" v="1.5"></senml>
<senml n="current" t="-1" v="1.6"></senml>
<senml n="current" v="1.7"></senml>
</sensml>
The SenML Stream is represented as a sensml tag that contains a The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record. The SenML Fields are series of senml tags for each SenML Record. The SenML Fields are
represents as XML attributes. The following table shows the mapping represents as XML attributes. The following table shows the mapping
of the SenML labels to the attribute names and types used in the XML of the SenML labels to the attribute names and types used in the XML
senml tags. senml tags.
+---------------+------+---------+ +---------------+------+---------+
| Name | XML | Type | | Name | XML | Type |
+---------------+------+---------+ +---------------+------+---------+
| Base Name | bn | string | | Base Name | bn | string |
skipping to change at page 15, line 24 skipping to change at page 15, line 24
attribute n { xsd:string }?, attribute n { xsd:string }?,
attribute s { xsd:double }?, attribute s { xsd:double }?,
attribute t { xsd:double }?, attribute t { xsd:double }?,
attribute u { xsd:string }?, attribute u { xsd:string }?,
attribute ut { xsd:double }?, attribute ut { xsd:double }?,
attribute v { xsd:double }?, attribute v { xsd:double }?,
attribute vb { xsd:boolean }?, attribute vb { xsd:boolean }?,
attribute vs { xsd:string }?, attribute vs { xsd:string }?,
attribute vd { xsd:string }?, attribute vd { xsd:string }?
attribute l { xsd:string }?
} }
sensml = sensml =
element sensml { element sensml {
senml+ senml+
} }
start = sensml start = sensml
8. EXI Representation (application/senml-exi) 8. EXI Representation (application/senml-exi)
skipping to change at page 16, line 7 skipping to change at page 16, line 5
EXI, the non-strict schema mode of EXI MAY be used. EXI, the non-strict schema mode of EXI MAY be used.
The EXI header option MUST be included. An EXI schemaID options MUST The EXI header option MUST be included. An EXI schemaID options MUST
be set to the value of "a" indicating the scheme provided in this be set to the value of "a" indicating the scheme provided in this
specification. Future revisions to the schema can change this specification. Future revisions to the schema can change this
schemaID to allow for backwards compatibility. When the data will be schemaID to allow for backwards compatibility. When the data will be
transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it
simply makes things larger and is redundant to information provided simply makes things larger and is redundant to information provided
in the Content-Type header. in the Content-Type header.
TODO - examples probably have the wrong setting the schemaID TODO - examples probably have the wrong setting for the schemaID
The following is the XSD Schema to be used for strict schema guided The following is the XSD Schema to be used for strict schema guided
EXI processing. It is generated from the RelaxNG. EXI processing. It is generated from the RelaxNG.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:senml" targetNamespace="urn:ietf:params:xml:ns:senml"
xmlns:ns1="urn:ietf:params:xml:ns:senml"> xmlns:ns1="urn:ietf:params:xml:ns:senml">
<xs:element name="senml"> <xs:element name="senml">
skipping to change at page 16, line 33 skipping to change at page 16, line 31
<xs:attribute name="bver" type="xs:int" /> <xs:attribute name="bver" type="xs:int" />
<xs:attribute name="n" type="xs:string" /> <xs:attribute name="n" type="xs:string" />
<xs:attribute name="s" type="xs:double" /> <xs:attribute name="s" type="xs:double" />
<xs:attribute name="t" type="xs:double" /> <xs:attribute name="t" type="xs:double" />
<xs:attribute name="u" type="xs:string" /> <xs:attribute name="u" type="xs:string" />
<xs:attribute name="ut" type="xs:double" /> <xs:attribute name="ut" type="xs:double" />
<xs:attribute name="v" type="xs:double" /> <xs:attribute name="v" type="xs:double" />
<xs:attribute name="vb" type="xs:boolean" /> <xs:attribute name="vb" type="xs:boolean" />
<xs:attribute name="vs" type="xs:string" /> <xs:attribute name="vs" type="xs:string" />
<xs:attribute name="vd" type="xs:string" /> <xs:attribute name="vd" type="xs:string" />
<xs:attribute name="l" type="xs:string" />
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="sensml"> <xs:element name="sensml">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element maxOccurs="unbounded" ref="ns1:senml" /> <xs:element maxOccurs="unbounded" ref="ns1:senml" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
The following shows a hexdump of the EXI produced from encoding the The following shows a hexdump of the EXI produced from encoding the
following XML example. Note this example is the same information as following XML example. Note this example is the same information as
the first example in Section 5.1.2 in JSON format. the first example in Section 5.1.2 in JSON format.
<sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml bn="urn:dev:ow:10e2073a01080063" n="voltage" u="V"
v="120.1"></senml>
<senml n="current" u="A" v="1.2"></senml>
</sensml>
Which compresses with EXI to the following displayed in hexdump: Which compresses with EXI to the following displayed in hexdump:
0000 a0 30 3d cd 95 b9 b5 b0 b9 9d 95 b8 b9 e1 cd 90 |.0=.............| 0000 a0 30 3d cd 95 b9 b5 b0 b9 9d 95 b8 b9 e1 cd 90 |.0=.............|
0010 80 eb ab 93 71 d3 23 2b b1 d3 7b b9 d1 89 83 29 |....q.#+..{....)| 0010 80 eb ab 93 71 d3 23 2b b1 d3 7b b9 d1 89 83 29 |....q.#+..{....)|
0020 91 81 b9 9b 09 81 89 81 c1 81 81 b1 9a 84 bb 37 |...............7| 0020 91 81 b9 9b 09 81 89 81 c1 81 81 b1 9a 84 bb 37 |...............7|
0030 b6 3a 30 b3 b2 90 1a b1 58 84 c0 33 04 b1 ba b9 |.:0.....X..3....| 0030 b6 3a 30 b3 b2 90 1a b1 58 84 c0 33 04 b1 ba b9 |.:0.....X..3....|
0040 39 32 b7 3a 10 1a 09 06 40 38 |92.:....@8| 0040 39 32 b7 3a 10 1a 09 06 40 38 |92.:....@8|
004a 004a
The above example used the bit packed form of EXI but it is also The above example used the bit packed form of EXI but it is also
possible to use a byte packed form of EXI which can makes it easier possible to use a byte packed form of EXI which can makes it easier
for a simple sensor to produce valid EXI without really implementing for a simple sensor to produce valid EXI without really implementing
EXI. Consider the example of a temperature sensor that produces a EXI. Consider the example of a temperature sensor that produces a
value in tenths of degrees Celsius over a range of 0.0 to 55.0. It value in tenths of degrees Celsius over a range of 0.0 to 55.0. It
would produce an XML SenML file such as: would produce an XML SenML file such as:
<sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml n="urn:dev:ow:10e2073a01080063" u="Cel" v="23.1"></senml>
</sensml>
The compressed form, using the byte alignment option of EXI, for the The compressed form, using the byte alignment option of EXI, for the
above XML is the following: above XML is the following:
0000 a0 00 48 81 ee 6c ad cd ad 85 cc ec ad c5 cf 0e |..H..l..........| 0000 a0 00 48 81 ee 6c ad cd ad 85 cc ec ad c5 cf 0e |..H..l..........|
0010 6c 80 01 06 1d 75 72 6e 3a 64 65 76 3a 6f 77 3a |l....urn:dev:ow:| 0010 6c 80 01 06 1d 75 72 6e 3a 64 65 76 3a 6f 77 3a |l....urn:dev:ow:|
0020 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 33 |10e2073a01080063| 0020 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 33 |10e2073a01080063|
0030 02 05 43 65 6c 01 00 e7 01 01 00 03 01 |..Cel........| 0030 02 05 43 65 6c 01 00 e7 01 01 00 03 01 |..Cel........|
003d 003d
A small temperature sensor devices that only generates this one EXI A small temperature sensor devices that only generates this one EXI
skipping to change at page 23, line 30 skipping to change at page 23, line 34
example, selecting a unit name of "mph" to indicate something example, selecting a unit name of "mph" to indicate something
that had nothing to do with velocity would be a bad choice, as that had nothing to do with velocity would be a bad choice, as
"mph" is commonly used to mean miles per hour. "mph" is commonly used to mean miles per hour.
7. The following should not be used because the are common SI 7. The following should not be used because the are common SI
prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z,
y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi.
8. The following units should not be used as they are commonly used 8. The following units should not be used as they are commonly used
to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G,
Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, Oe, Gb, sb, Lmb, mph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal,
BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh.
9. The unit names are case sensitive and the correct case needs to 9. The unit names are case sensitive and the correct case needs to
be used, but symbols that differ only in case should not be be used, but symbols that differ only in case should not be
allocated. allocated.
10. A number after a unit typically indicates the previous unit 10. A number after a unit typically indicates the previous unit
raised to that power, and the / indicates that the units that raised to that power, and the / indicates that the units that
follow are the reciprocal. A unit should have only one / in the follow are the reciprocal. A unit should have only one / in the
name. name.
skipping to change at page 29, line 8 skipping to change at page 29, line 10
considerations, such as the current temperature in a given city, to considerations, such as the current temperature in a given city, to
highly sensitive medical or location data. This specification highly sensitive medical or location data. This specification
provides no security protection for the data but is meant to be used 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 inside another container or transport protocol such as S/MIME or HTTP
with TLS that can provide integrity, confidentiality, and with TLS that can provide integrity, confidentiality, and
authentication information about the source of the data. authentication information about the source of the data.
14. Acknowledgement 14. Acknowledgement
We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay
Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, Carsten Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, and
Bormann, and Christian Amsuess for their review comments. Christian Amsuess for their review comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[BIPM] Bureau International des Poids et Mesures, "The [BIPM] Bureau International des Poids et Mesures, "The
International System of Units (SI)", 8th edition, 2006. International System of Units (SI)", 8th edition, 2006.
[IEEE.754.1985] [IEEE.754.1985]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
 End of changes. 12 change blocks. 
13 lines changed or deleted 46 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/