RFC 8428
Sensor Measurement Lists (SenML)
12.3. Media Type Registrations
The registrations in the subsections below follow the procedures specified in [RFC6838] and [RFC7303]. This document registers media types for each serialization format of SenML (JSON, CBOR, XML, and EXI) and also a corresponding set of media types for streaming use (SenSML; see Section 4.8). Clipboard formats are defined for the JSON and XML forms of SenML but not for streams or non-textual formats. The reason there are both SenML and the streaming SenSML formats is that they are not the same data formats, and they require separate negotiation to understand if they are supported and which one is being used. The non-streaming format is required to have some sort of end-of-pack syntax that indicates there will be no more records. Many implementations that receive SenML wait for this end-of-pack marker before processing any of the records. On the other hand, with the streaming formats, it is explicitly not required to wait for this
end-of-pack marker. Many implementations that produce streaming SenSML will never send this end-of-pack marker, so implementations that receive streaming SenSML cannot wait for the end-of-pack marker before they start processing the records. Given that SenML and streaming SenML are different data formats, and considering the requirement for separate negotiation, a media type for each one is needed.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 [RFC8259]. See RFC 8428 for details. This simplifies implementation of a 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: See Section 13 of RFC 8428. Interoperability considerations: Applications MUST ignore any JSON key-value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible 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 8428 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+json is supported by using fragment identifiers as specified by RFC 8428.
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): senml
Windows Clipboard Name: "JSON Sensor Measurement List"
Macintosh file type code(s): none
Macintosh Universal Type Identifier code: org.ietf.senml-json
conforms to public.text
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
12.3.2. sensml+json Media Type Registration
Type name: application
Subtype name: sensml+json
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as using a subset of the
encoding allowed in [RFC8259]. See RFC 8428 for details. This
simplifies implementation of a 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: See Section 13 of RFC 8428.
Interoperability considerations: Applications MUST ignore any JSON
key-value pairs that they do not understand unless the key ends with
the "_" character, in which case an error MUST be generated. This
allows backwards-compatible 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 8428
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/sensml+json is supported by using fragment identifiers as
specified by RFC 8428.
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): sensml
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
12.3.3. senml+cbor Media Type Registration
Type name: application
Subtype name: senml+cbor
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as using [RFC7049]. See RFC
8428 for details.
Security considerations: See Section 13 of RFC 8428. Interoperability considerations: Applications MUST ignore any key- value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible 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 8428 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+cbor is supported by using fragment identifiers as specified by RFC 8428. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): senmlc Macintosh file type code(s): none Macintosh Universal Type Identifier code: org.ietf.senml-cbor conforms to public.data 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
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 8428 for details. Security considerations: See Section 13 of RFC 8428. Interoperability considerations: Applications MUST ignore any key- value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible 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 8428 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/sensml+cbor is supported by using fragment identifiers as specified by RFC 8428. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): sensmlc 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: IESG12.3.5. senml+xml Media Type Registration
Type name: application Subtype name: senml+xml Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC 8428 for details. Security considerations: See Section 13 of RFC 8428. Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible 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 SenML Pack. Published specification: RFC 8428 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 8428. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): senmlx
Windows Clipboard Name: "XML Sensor Measurement List"
Macintosh file type code(s): none
Macintosh Universal Type Identifier code: org.ietf.senml-xml
conforms to public.xml
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
12.3.6. sensml+xml Media Type Registration
Type name: application
Subtype name: sensml+xml
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as using
[W3C.REC-xml-20081126]. See RFC 8428 for details.
Security considerations: See Section 13 of RFC 8428.
Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand unless the attribute
name ends with the "_" character, in which case an error MUST be
generated. This allows backwards-compatible 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 SenML Pack.
Published specification: RFC 8428
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/sensml+xml is supported by using fragment identifiers as
specified by RFC 8428.
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): sensmlx
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
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 8428 for details.
Security considerations: See Section 13 of RFC 8428.
Interoperability considerations: Applications MUST ignore any XML
tags or attributes that they do not understand unless the attribute
name ends with the "_" character, in which case an error MUST be
generated. This allows backwards-compatible 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 SenML Pack. Further information on
using schemas to guide the EXI can be found in RFC 8428.
Published specification: RFC 8428
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-exi is supported by using fragment identifiers as
specified by RFC 8428.
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): senmle
Macintosh file type code(s): none
Macintosh Universal Type Identifier code: org.ietf.senml-exi
conforms to public.data
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
12.3.8. sensml-exi Media Type Registration
Type name: application
Subtype name: sensml-exi
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as using
[W3C.REC-exi-20140211]. See RFC 8428 for details.
Security considerations: See Section 13 of RFC 8428. Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible 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 SenML Pack. Further information on using schemas to guide the EXI can be found in RFC 8428. Published specification: RFC 8428 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/sensml-exi is supported by using fragment identifiers as specified by RFC 8428. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): 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
12.4. XML Namespace Registration
This document registers the following XML namespace 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 namespaces12.5. CoAP Content-Format Registration
IANA has assigned CoAP Content-Format IDs for the SenML media types in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [RFC7252]. IDs for the JSON, CBOR, and EXI Content-Formats have been assigned in the 0-255 range (Expert Review), and IDs for the XML Content-Formats have been assigned in the 256-9999 range (IETF Review or IESG Approval). The assigned IDs are shown in the table below: +-------------------------+----------+-----+-----------+ | Media Type | Encoding | ID | Reference | +-------------------------+----------+-----+-----------+ | application/senml+json | - | 110 | RFC 8428 | | application/sensml+json | - | 111 | RFC 8428 | | application/senml+cbor | - | 112 | RFC 8428 | | application/sensml+cbor | - | 113 | RFC 8428 | | application/senml-exi | - | 114 | RFC 8428 | | application/sensml-exi | - | 115 | RFC 8428 | | application/senml+xml | - | 310 | RFC 8428 | | application/sensml+xml | - | 311 | RFC 8428 | +-------------------------+----------+-----+-----------+ Table 8: CoAP Content-Format IDs13. Security Considerations
Sensor data presented with SenML can contain a wide array of information that ranges from very public (such as the outside temperature in a given city) to very private (such as patient health information that requires integrity and confidentiality protection). When SenML is used for configuration or actuation, it can be used to change the state of systems and also impact the physical world, e.g., by turning off a heater or opening a lock. Malicious use of SenML to change system state could have severe consequences, potentially including violation of physical security, property damage, and even loss of life.
SenML formats alone do not provide any security and instead rely on the protocol that carries them to provide security. Applications using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate. In particular, for sensitive sensor data and actuation use, it is important to ensure that proper security mechanisms are used to provide, e.g., confidentiality, data integrity, and authentication as appropriate for the usage. SenML formats defined by this specification do not contain any executable content. However, future extensions could potentially embed application-specific executable content in the data. SenML Records are intended to be interpreted in the context of any applicable base values. If Records become separated from the Record that establishes the base values, the data will be useless or, worse, wrong. Care needs to be taken in keeping the integrity of a Pack that contains unresolved SenML Records (see Section 4.6). See also Section 14.14. Privacy Considerations
Sensor data can range from information with almost no privacy 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 transfer protocol such as S/MIME [RFC5751] or HTTP with TLS [RFC2818] that can provide integrity, confidentiality, and authentication information about the source of the data. The Name fields need to uniquely identify the sources or destinations of the values in a SenML Pack. However, the use of long-term stable and unique identifiers can be problematic for privacy reasons [RFC6973], depending on the application and the potential of these identifiers to be used in correlation with other information. They should be used with care or avoided, for example, as described for IPv6 addresses in [RFC7721].
15. References
15.1. Normative References
[BIPM] Bureau International des Poids et Mesures, "The International System of Units (SI)", 8th Edition, 2006. [IEEE.754] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754. [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the International System of Units (SI)", NIST Special Publication 811, DOI 10.6028/NIST.SP.811e2008, March 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://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, <https://www.rfc-editor.org/info/rfc7049>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RNC] ISO/IEC, "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar- based validation -- RELAX NG", ISO/IEC 19757-2, Annex C: RELAX NG Compact syntax, December 2008. [TIME_T] The Open Group Base Specifications, "Open Group Standard - Vol. 1: Base Definitions, Issue 7", Section 4.16, "Seconds Since the Epoch", IEEE Standard 1003.1, 2018, <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16>. [W3C.REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", W3C 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)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>. [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. [XPointerElement] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer element() Scheme", W3C Recommendation REC-xptr-element, March 2003, <https://www.w3.org/TR/2003/REC-xptr-element-20030325/>.
[XPointerFramework] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Framework", W3C Recommendation REC-XPointer-Framework, March 2003, <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.15.2. Informative References
[AN1796] Linke, B., "Overview of 1-Wire Technology and Its Use", Maxim Integrated, Tutorial 1796, June 2008, <http://pdfserv.maximintegrated.com/en/an/AN1796.pdf>. [CDDL-CBOR] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures", Work in Progress, draft-ietf-cbor-cddl-05, August 2018. [DEVICE-URN] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", Work in Progress, draft-ietf-core-dev-urn-02, July 2018. [IEEE802.1AS] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Standard 802.1AS. [IEEE802.1BA] IEEE, "IEEE Standard for Local and metropolitan area networks--Audio Video Bridging (AVB) Systems", IEEE Standard 802.1BA. [ISO-80000-5] ISO, "Quantities and units - Part 5: Thermodynamics", ISO 80000-5, Edition 1.0, May 2007. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>. [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, <https://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, <https://www.rfc-editor.org/info/rfc4122>. [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, DOI 10.17487/RFC4151, October 2005, <https://www.rfc-editor.org/info/rfc4151>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>. [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>. [RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment Identifiers for the text/csv Media Type", RFC 7111, DOI 10.17487/RFC7111, January 2014, <https://www.rfc-editor.org/info/rfc7111>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[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, <https://www.rfc-editor.org/info/rfc7721>. [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>. [RID-CoRE] Shelby, Z., Vial, M., Groves, C., Zhu, J., and B. Silverajan, Ed., "Reusable Interface Definitions for Constrained RESTful Environments", Work in Progress, draft-ietf-core-interfaces-12, June 2018. [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units of Measure", Version 2.1, Regenstrief Institute and the UCUM Organization, November 2017, <http://unitsofmeasure.org/ucum.html>.Acknowledgements
We would like to thank Alexander Pelov, Alexey Melnikov, Andrew McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter Saint-Andre, Roni Even, and Stephen Farrell, for their review comments.
Authors' Addresses
Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Zach Shelby ARM 150 Rose Orchard San Jose 95134 United States of America 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