Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8428

Sensor Measurement Lists (SenML)

Pages: 54
Proposed Standard
Errata
Updated by:  9100
Part 3 of 3 – Pages 36 to 54
First   Prev   None

Top   ToC   RFC8428 - Page 36   prevText

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
Top   ToC   RFC8428 - Page 37
   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.
Top   ToC   RFC8428 - Page 38
   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
Top   ToC   RFC8428 - Page 39
   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.
Top   ToC   RFC8428 - Page 40
   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
Top   ToC   RFC8428 - Page 41

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
Top   ToC   RFC8428 - Page 42
   Restrictions on usage: None

   Author: Cullen Jennings <fluffy@iii.ca>

   Change controller: IESG

12.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
Top   ToC   RFC8428 - Page 43
      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.
Top   ToC   RFC8428 - Page 44
   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.
Top   ToC   RFC8428 - Page 45
   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.
Top   ToC   RFC8428 - Page 46
   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
Top   ToC   RFC8428 - Page 47

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 namespaces

12.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 IDs

13. 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.
Top   ToC   RFC8428 - Page 48
   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].
Top   ToC   RFC8428 - Page 49

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>.
Top   ToC   RFC8428 - Page 50
   [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/>.
Top   ToC   RFC8428 - Page 51
   [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>.
Top   ToC   RFC8428 - Page 52
   [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>.
Top   ToC   RFC8428 - Page 53
   [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.
Top   ToC   RFC8428 - Page 54

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