draft-ietf-core-senml-05.txt | draft-ietf-core-senml-06.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: September 14, 2017 ARM | Expires: November 5, 2017 ARM | |||
J. Arkko | J. Arkko | |||
A. Keranen | A. Keranen | |||
Ericsson | Ericsson | |||
C. Bormann | C. Bormann | |||
Universitaet Bremen TZI | Universitaet Bremen TZI | |||
March 13, 2017 | May 4, 2017 | |||
Media Types for Sensor Measurement Lists (SenML) | Media Types for Sensor Measurement Lists (SenML) | |||
draft-ietf-core-senml-05 | draft-ietf-core-senml-06 | |||
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 September 14, 2017. | This Internet-Draft will expire on November 5, 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 21, line 45 ¶ | skipping to change at page 21, line 45 ¶ | |||
0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| | 0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| | |||
0030 01 |.| | 0030 01 |.| | |||
0031 | 0031 | |||
A small temperature sensor devices that only generates this one EXI | A small temperature sensor devices that only generates this one EXI | |||
file does not really need an full EXI implementation. It can simply | file does not really need an full EXI implementation. It can simply | |||
hard code the output replacing the 1-wire device ID starting at byte | hard code the output replacing the 1-wire device ID starting at byte | |||
0x20 and going to byte 0x2F with it's device ID, and replacing the | 0x20 and going to byte 0x2F with it's device ID, and replacing the | |||
value "0xe7 0x01" at location 0x37 and 0x38 with the current | value "0xe7 0x01" at location 0x37 and 0x38 with the current | |||
temperature. The EXI Specification [W3C.REC-exi-20140211] contains | temperature. The EXI Specification [W3C.REC-exi-20140211] contains | |||
the full information 'on how floating point numbers are represented, | the full information on how floating point numbers are represented, | |||
but for the purpose of this sensor, the temperature can be converted | but for the purpose of this sensor, the temperature can be converted | |||
to an integer in tenths of degrees (231 in this example). EXI stores | to an integer in tenths of degrees (231 in this example). EXI stores | |||
7 bits of the integer in each byte with the top bit set to one if | 7 bits of the integer in each byte with the top bit set to one if | |||
there are further bytes. So the first bytes at is set to low 7 bits | there are further bytes. So the first bytes at is set to low 7 bits | |||
of the integer temperature in tenths of degrees plus 0x80. In this | of the integer temperature in tenths of degrees plus 0x80. In this | |||
example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the | example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the | |||
integer temperature in tenths of degrees right shifted 7 bits. In | integer temperature in tenths of degrees right shifted 7 bits. In | |||
this example 231 >> 7 = 0x01. | this example 231 >> 7 = 0x01. | |||
9. Fragment Identification Methods | 9. Fragment Identification Methods | |||
skipping to change at page 22, line 20 ¶ | skipping to change at page 22, line 20 ¶ | |||
some applications it may be useful to be able to refer with a | some applications it may be useful to be able to refer with a | |||
Fragment Identifier to a single record, or a set of records, in a | Fragment Identifier to a single record, or a set of records, in a | |||
Pack. The fragment identifier is only interpreted by a client and | Pack. The fragment identifier is only interpreted by a client and | |||
does not impact retrieval of a representation. The SenML Fragment | does not impact retrieval of a representation. The SenML Fragment | |||
Identification is modeled after CSV Fragment Identifiers [RFC7111]. | Identification is modeled after CSV Fragment Identifiers [RFC7111]. | |||
To select a single SenML Record, the "rec" scheme followed by a | To select a single SenML Record, the "rec" scheme followed by a | |||
single number is used. For the purpose of numbering records, the | single number is used. For the purpose of numbering records, the | |||
first record is at position 1. A range of records can be selected by | first record is at position 1. A range of records can be selected by | |||
giving the first and the last record number separated by a '-' | giving the first and the last record number separated by a '-' | |||
character. Instead of the second number, the "*" character can be | character. Instead of the second number, the '*' character can be | |||
used to indicate the last Senml Record in the Pack. A set of records | used to indicate the last Senml Record in the Pack. A set of records | |||
can also be selected using a comma separated list of record positions | can also be selected using a comma separated list of record positions | |||
or ranges. | or ranges. | |||
(We use the term "selecting a record" for identifying it as part of | (We use the term "selecting a record" for identifying it as part of | |||
the fragment, not in the sense of isolating it from the Pack -- the | the fragment, not in the sense of isolating it from the Pack -- the | |||
record still needs to be interpreted as part of the Pack, e.g., using | record still needs to be interpreted as part of the Pack, e.g., using | |||
the base values defined in record 1.) | the base values defined in record 1.) | |||
9.1. Fragment Identification Examples | 9.1. Fragment Identification Examples | |||
skipping to change at page 27, line 35 ¶ | skipping to change at page 27, line 35 ¶ | |||
| %EL | Percentage (remaining battery | float | RFC-AAAA | | | %EL | Percentage (remaining battery | float | RFC-AAAA | | |||
| | energy level) | | | | | | energy level) | | | | |||
| EL | seconds (remaining battery energy | float | RFC-AAAA | | | EL | seconds (remaining battery energy | float | RFC-AAAA | | |||
| | level) | | | | | | level) | | | | |||
| 1/s | 1 per second (event rate) | float | RFC-AAAA | | | 1/s | 1 per second (event rate) | float | RFC-AAAA | | |||
| 1/min | 1 per minute (event rate, "rpm")* | 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 | | | beat/min | 1 per minute (Heart rate in beats | float | RFC-AAAA | | |||
| | per minute)* | | | | | | per minute)* | | | | |||
| beats | 1 (Cumulative number of heart | float | RFC-AAAA | | | beats | 1 (Cumulative number of heart | float | RFC-AAAA | | |||
| | beats)* | | | | | | beats)* | | | | |||
| S/m | Siemens per meter (conductivity) | float | RFC-AAAA | | ||||
+----------+------------------------------------+-------+-----------+ | +----------+------------------------------------+-------+-----------+ | |||
Table 5 | Table 5 | |||
o Note 1: A value of 0.0 indicates the switch is off while 1.0 | o Note 1: 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 | indicates on and 0.5 would be half on. The preferred name of this | |||
unit is "/". For historical reasons, the name "%" is also | unit is "/". For historical reasons, the name "%" is also | |||
provided for the same unit - but note that while that name | provided for the same unit - but note that while that name | |||
strongly suggests a percentage (0..100) -- it is however NOT a | strongly suggests a percentage (0..100) -- it is however NOT a | |||
percentage, but the absolute ratio! | percentage, but the absolute ratio! | |||
skipping to change at page 42, line 38 ¶ | skipping to change at page 42, line 38 ¶ | |||
16. References | 16. References | |||
16.1. Normative References | 16.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, | |||
"Standard for Binary Floating-Point Arithmetic", IEEE | "Standard for Binary Floating-Point Arithmetic", | |||
Standard 754, August 1985. | IEEE Standard 754, August 1985. | |||
[NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the | [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the | |||
International System of Units (SI)", NIST Special | International System of Units (SI)", NIST Special | |||
Publication 811, 2008. | Publication 811, 2008. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||
RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, | DOI 10.17487/RFC3688, January 2004, | |||
<http://www.rfc-editor.org/info/rfc3688>. | <http://www.rfc-editor.org/info/rfc3688>. | |||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<http://www.rfc-editor.org/info/rfc4648>. | <http://www.rfc-editor.org/info/rfc4648>. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
DOI 10.17487/RFC5226, May 2008, | DOI 10.17487/RFC5226, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5226>. | <http://www.rfc-editor.org/info/rfc5226>. | |||
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
Specifications and Registration Procedures", BCP 13, RFC | Specifications and Registration Procedures", BCP 13, | |||
6838, DOI 10.17487/RFC6838, January 2013, | RFC 6838, DOI 10.17487/RFC6838, January 2013, | |||
<http://www.rfc-editor.org/info/rfc6838>. | <http://www.rfc-editor.org/info/rfc6838>. | |||
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | |||
October 2013, <http://www.rfc-editor.org/info/rfc7049>. | October 2013, <http://www.rfc-editor.org/info/rfc7049>. | |||
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March | Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March | |||
2014, <http://www.rfc-editor.org/info/rfc7159>. | 2014, <http://www.rfc-editor.org/info/rfc7159>. | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ | Application Protocol (CoAP)", RFC 7252, | |||
RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7252>. | <http://www.rfc-editor.org/info/rfc7252>. | |||
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, | [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, | |||
DOI 10.17487/RFC7303, July 2014, | DOI 10.17487/RFC7303, July 2014, | |||
<http://www.rfc-editor.org/info/rfc7303>. | <http://www.rfc-editor.org/info/rfc7303>. | |||
[W3C.REC-exi-20140211] | [W3C.REC-exi-20140211] | |||
Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, | Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, | |||
"Efficient XML Interchange (EXI) Format 1.0 (Second | "Efficient XML Interchange (EXI) Format 1.0 (Second | |||
Edition)", World Wide Web Consortium Recommendation REC- | Edition)", World Wide Web Consortium Recommendation REC- | |||
skipping to change at page 44, line 13 ¶ | skipping to change at page 44, line 13 ¶ | |||
<http://www.w3.org/TR/2008/REC-xml-20081126>. | <http://www.w3.org/TR/2008/REC-xml-20081126>. | |||
16.2. Informative References | 16.2. Informative References | |||
[I-D.arkko-core-dev-urn] | [I-D.arkko-core-dev-urn] | |||
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource | Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource | |||
Names for Device Identifiers", draft-arkko-core-dev-urn-03 | Names for Device Identifiers", draft-arkko-core-dev-urn-03 | |||
(work in progress), July 2012. | (work in progress), July 2012. | |||
[I-D.greevenbosch-appsawg-cbor-cddl] | [I-D.greevenbosch-appsawg-cbor-cddl] | |||
Vigano, C. and H. Birkholz, "CBOR data definition language | Birkholz, H., Vigano, C., and C. Bormann, "CBOR data | |||
(CDDL): a notational convention to express CBOR data | definition language (CDDL): a notational convention to | |||
structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work | express CBOR data structures", draft-greevenbosch-appsawg- | |||
in progress), September 2016. | cbor-cddl-10 (work in progress), March 2017. | |||
[I-D.ietf-core-links-json] | [I-D.ietf-core-links-json] | |||
Li, K., Rahman, A., and C. Bormann, "Representing CoRE | Li, K., Rahman, A., and C. Bormann, "Representing | |||
Formats in JSON and CBOR", draft-ietf-core-links-json-06 | Constrained RESTful Environments (CoRE) Link Format in | |||
(work in progress), July 2016. | JSON and CBOR", draft-ietf-core-links-json-08 (work in | |||
progress), April 2017. | ||||
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, | [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, | |||
May 1997, <http://www.rfc-editor.org/info/rfc2141>. | May 1997, <http://www.rfc-editor.org/info/rfc2141>. | |||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, RFC | Resource Identifier (URI): Generic Syntax", STD 66, | |||
3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<http://www.rfc-editor.org/info/rfc3986>. | <http://www.rfc-editor.org/info/rfc3986>. | |||
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | |||
Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI | Unique IDentifier (UUID) URN Namespace", RFC 4122, | |||
10.17487/RFC4122, July 2005, | DOI 10.17487/RFC4122, July 2005, | |||
<http://www.rfc-editor.org/info/rfc4122>. | <http://www.rfc-editor.org/info/rfc4122>. | |||
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 | [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 | |||
Address Text Representation", RFC 5952, DOI 10.17487/ | Address Text Representation", RFC 5952, | |||
RFC5952, August 2010, | DOI 10.17487/RFC5952, August 2010, | |||
<http://www.rfc-editor.org/info/rfc5952>. | <http://www.rfc-editor.org/info/rfc5952>. | |||
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<http://www.rfc-editor.org/info/rfc6690>. | <http://www.rfc-editor.org/info/rfc6690>. | |||
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment | [RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment | |||
Identifiers for the text/csv Media Type", RFC 7111, DOI | Identifiers for the text/csv Media Type", RFC 7111, | |||
10.17487/RFC7111, January 2014, | DOI 10.17487/RFC7111, January 2014, | |||
<http://www.rfc-editor.org/info/rfc7111>. | <http://www.rfc-editor.org/info/rfc7111>. | |||
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy | [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy | |||
Considerations for IPv6 Address Generation Mechanisms", | Considerations for IPv6 Address Generation Mechanisms", | |||
RFC 7721, DOI 10.17487/RFC7721, March 2016, | RFC 7721, DOI 10.17487/RFC7721, March 2016, | |||
<http://www.rfc-editor.org/info/rfc7721>. | <http://www.rfc-editor.org/info/rfc7721>. | |||
[UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units | [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units | |||
of Measure (UCUM)", Regenstrief Institute and Indiana | of Measure (UCUM)", Regenstrief Institute and Indiana | |||
University School of Informatics, 2013, | University School of Informatics, 2013, | |||
End of changes. 17 change blocks. | ||||
29 lines changed or deleted | 31 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/ |