Media Types for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8428.
|
|
|---|---|---|---|
| Authors | Cullen Fluffy Jennings , Zach Shelby , Jari Arkko , Ari Keränen , Carsten Bormann | ||
| Last updated | 2016-10-31 | ||
| Replaces | draft-jennings-core-senml | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-13)
by Roni Even
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8428 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | (None) |
draft-ietf-core-senml-04
Internet-Draft SenML October 2016 11.3.2. senml+cbor Media Type Registration Type name: application Subtype name: senml+cbor and 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. 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 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. Additional information: Magic number(s): none File extension(s): senmlc and sensmlc Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca> Intended usage: COMMON Jennings, et al. Expires May 4, 2017 [Page 31] Internet-Draft SenML October 2016 Restrictions on usage: None Author: Cullen Jennings <fluffy@iii.ca> Change controller: IESG 11.3.3. senml+xml Media Type Registration Type name: application Subtype name: senml+xml and 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. Interoperability considerations: Applications should ignore any tags or attributes that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" attribute in the senml 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. Additional information: Magic number(s): none File extension(s): senmlx and sensmlx Jennings, et al. Expires May 4, 2017 [Page 32] Internet-Draft SenML October 2016 Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca> Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings <fluffy@iii.ca> Change controller: IESG 11.3.4. senml+exi Media Type Registration Type name: application Subtype name: senml+exi and 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. Interoperability considerations: Applications should ignore any tags or attributes that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" attribute in the senml 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 Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental Jennings, et al. Expires May 4, 2017 [Page 33] Internet-Draft SenML October 2016 information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senmle and sensmle Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca> Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings <fluffy@iii.ca> Change controller: IESG 11.4. XML Namespace Registration This document registers the following XML namespaces in the IETF XML registry defined in [RFC3688]. URI: urn:ietf:params:xml:ns:senml Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces 11.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. Jennings, et al. Expires May 4, 2017 [Page 34] Internet-Draft SenML October 2016 +-------------------------+-----+ | 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 12. Security Considerations See Section 13. Further discussion of security properties can be found in Section 11.3. 13. 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. 14. Acknowledgement We would like to thank Alexander Pelov, Andrew McClure, Andrew Mcgregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, Daniel Peintner, Jan-Piet Mens, Joe Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, and Stephen Farrell, for their review comments. 15. References 15.1. Normative References [BIPM] Bureau International des Poids et Mesures, "The International System of Units (SI)", 8th edition, 2006. Jennings, et al. Expires May 4, 2017 [Page 35] Internet-Draft SenML October 2016 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the International System of Units (SI)", NIST Special Publication 811, 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <http://www.rfc-editor.org/info/rfc7049>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <http://www.rfc-editor.org/info/rfc7303>. Jennings, et al. Expires May 4, 2017 [Page 36] Internet-Draft SenML October 2016 [W3C.REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC- exi-20140211, February 2014, <http://www.w3.org/TR/2014/REC-exi-20140211>. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>. 15.2. Informative References [I-D.arkko-core-dev-urn] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", draft-arkko-core-dev-urn-03 (work in progress), July 2012. [I-D.greevenbosch-appsawg-cbor-cddl] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work in progress), September 2016. [I-D.ietf-core-links-json] Li, K., Rahman, A., and C. Bormann, "Representing CoRE Formats in JSON and CBOR", draft-ietf-core-links-json-06 (work in progress), July 2016. [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>. Jennings, et al. Expires May 4, 2017 [Page 37] Internet-Draft SenML October 2016 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>. [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>. [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units of Measure (UCUM)", Regenstrief Institute and Indiana University School of Informatics, 2013, <http://unitsofmeasure.org/ucum.html>. Appendix A. Links Extension An attribute to support a link extension for SenML is defined as a string attribute by this specification. The link extension can be used for additional information about a SenML Record. The definition and usage of the contents of this value are specified in [I-D.ietf-core-links-json]. For JSON and XML the attribute has a label of "l" and a value that is a string. The following shows an example of the links extension. [ {"bn":"urn:dev:ow:10e2073a01080063;","bt":1.320078429e+09, "l":"[{\"href\":\"humidity\",\"foo\":\"bar1\"}", "n":"temperature","u":"Cel","v":27.2}, {"n":"humidity","u":"%RH","v":80} ] Authors' Addresses Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Jennings, et al. Expires May 4, 2017 [Page 38] Internet-Draft SenML October 2016 Zach Shelby ARM 150 Rose Orchard San Jose 95134 USA Phone: +1-408-203-9434 Email: zach.shelby@arm.com Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Jennings, et al. Expires May 4, 2017 [Page 39]