--- 1/draft-ietf-core-senml-05.txt 2017-05-04 12:13:08.842280673 -0700 +++ 2/draft-ietf-core-senml-06.txt 2017-05-04 12:13:08.926282692 -0700 @@ -1,24 +1,24 @@ Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track Z. Shelby -Expires: September 14, 2017 ARM +Expires: November 5, 2017 ARM J. Arkko A. Keranen Ericsson C. Bormann Universitaet Bremen TZI - March 13, 2017 + May 4, 2017 Media Types for Sensor Measurement Lists (SenML) - draft-ietf-core-senml-05 + draft-ietf-core-senml-06 Abstract This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -901,21 +901,21 @@ 0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......| 0030 01 |.| 0031 A small temperature sensor devices that only generates this one EXI 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 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 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 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 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 example 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the integer temperature in tenths of degrees right shifted 7 bits. In this example 231 >> 7 = 0x01. 9. Fragment Identification Methods @@ -924,21 +924,21 @@ 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 Pack. The fragment identifier is only interpreted by a client and does not impact retrieval of a representation. The SenML Fragment Identification is modeled after CSV Fragment Identifiers [RFC7111]. To select a single SenML Record, the "rec" scheme followed by a 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 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 can also be selected using a comma separated list of record positions or ranges. (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 record still needs to be interpreted as part of the Pack, e.g., using the base values defined in record 1.) 9.1. Fragment Identification Examples @@ -1180,20 +1180,21 @@ | %EL | Percentage (remaining battery | float | RFC-AAAA | | | energy level) | | | | EL | seconds (remaining battery energy | float | RFC-AAAA | | | level) | | | | 1/s | 1 per second (event rate) | 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 | | | per minute)* | | | | beats | 1 (Cumulative number of heart | float | RFC-AAAA | | | beats)* | | | + | S/m | Siemens per meter (conductivity) | float | RFC-AAAA | +----------+------------------------------------+-------+-----------+ Table 5 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 unit is "/". For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! @@ -1889,61 +1890,61 @@ 16. References 16.1. Normative References [BIPM] Bureau International des Poids et Mesures, "The International System of Units (SI)", 8th edition, 2006. [IEEE.754.1985] Institute of Electrical and Electronics Engineers, - "Standard for Binary Floating-Point Arithmetic", IEEE - Standard 754, August 1985. + "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, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [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, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type - Specifications and Registration Procedures", BCP 13, RFC - 6838, DOI 10.17487/RFC6838, January 2013, + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained - Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ - RFC7252, June 2014, + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . [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- @@ -1958,55 +1959,56 @@ . 16.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. + Birkholz, H., Vigano, C., and C. Bormann, "CBOR data + definition language (CDDL): a notational convention to + express CBOR data structures", draft-greevenbosch-appsawg- + cbor-cddl-10 (work in progress), March 2017. [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. + Li, K., Rahman, A., and C. Bormann, "Representing + Constrained RESTful Environments (CoRE) Link Format in + 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, May 1997, . [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, + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally - Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI - 10.17487/RFC4122, July 2005, + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 - Address Text Representation", RFC 5952, DOI 10.17487/ - RFC5952, August 2010, + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [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, + Identifiers for the text/csv Media Type", RFC 7111, + DOI 10.17487/RFC7111, January 2014, . [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, . [UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units of Measure (UCUM)", Regenstrief Institute and Indiana University School of Informatics, 2013,