--- 1/draft-ietf-core-senml-08.txt 2017-06-29 12:13:34.953450952 -0700 +++ 2/draft-ietf-core-senml-09.txt 2017-06-29 12:13:35.053453354 -0700 @@ -1,24 +1,24 @@ Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track Z. Shelby -Expires: November 24, 2017 ARM +Expires: December 31, 2017 ARM J. Arkko A. Keranen Ericsson C. Bormann Universitaet Bremen TZI - May 23, 2017 + June 29, 2017 Media Types for Sensor Measurement Lists (SenML) - draft-ietf-core-senml-08 + draft-ietf-core-senml-09 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 November 24, 2017. + This Internet-Draft will expire on December 31, 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 @@ -223,21 +223,21 @@ presented using the SenML data model. SenML Pack: One or more SenML Records in an array structure. 4. SenML Structure and Semantics Each SenML Pack carries a single array that represents a set of measurements and/or parameters. This array contains a series of SenML Records with several attributes described below. There are two kind of attributes: base and regular. The base attributes can be - included in the any SenML Record and they apply to the entries in the + included in any SenML Record and they apply to the entries in the Record. Each base attribute also applies to all Records after it up to, but not including, the next Record that has that same base attribute. All base attributes are optional. Regular attributes can be included in any SenML Record and apply only to that Record. 4.1. Base attributes Base Name: This is a string that is prepended to the names found in the entries. @@ -264,21 +264,21 @@ Name: Name of the sensor or parameter. When appended to the Base Name attribute, this must result in a globally unique identifier for the resource. The name is optional, if the Base Name is present. If the name is missing, Base Name must uniquely identify the resource. This can be used to represent a large array of measurements from the same sensor without having to repeat its identifier on every measurement. Unit: Units for a measurement value. Optional. - Value Value of the entry. Optional if a Sum value is present, + Value: Value of the entry. Optional if a Sum value is present, otherwise required. Values are represented using basic data types. This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value"). Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value field. Sum: Integrated sum of the values over time. Optional. This attribute is in the units specified in the Unit value multiplied by seconds. @@ -301,22 +301,22 @@ Systems reading one of the objects MUST check for the Version attribute. If this value is a version number larger than the version which the system understands, the system SHOULD NOT use this object. This allows the version number to indicate that the object contains mandatory to understand attributes. New version numbers can only be defined in an RFC that updates this specification or it successors. The Name value is concatenated to the Base Name value to get the name of the sensor. The resulting name needs to uniquely identify and differentiate the sensor from all others. It is RECOMMENDED that the - full names are represented as URIs or URNs [RFC2141]. One way to - create a unique name is to include some bit string that has + full names are represented as URIs [RFC3986] or URNs [RFC2141]. One + way to create a unique name is to include some bit string that has guaranteed uniqueness (such as a 1-wire address) that is assigned to the device. Some of the examples in this draft use the device URN type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to generate a unique name. Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care or avoided as described in [RFC7721]. The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to @@ -1014,21 +1014,21 @@ positive, the sum should never get smaller; so if the sum does get smaller, the application will know that one of the situations listed above has happened. 11. CDDL For reference, the JSON and CBOR representations can be described with the common CDDL [I-D.greevenbosch-appsawg-cbor-cddl] specification in Figure 1. - SenML-Pack = [ record, * record] + SenML-Pack = [1* record] record = { ? bn => tstr, ; Base Name ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base value ? bs => numeric, ; Base sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? u => tstr, ; Units @@ -1039,21 +1039,23 @@ ? ( v => numeric // ; Numeric Value vs => tstr // ; String Value vb => bool // ; Boolean Value vd => binary-value ) ; Data Value * key-value-pair } ; now define the generic versions key-value-pair = ( label => value ) - label = tstr .regexp "[A-Za-z0-9][-_:.A-Za-z0-9]*" / uint + label = non-b-label / b-label + non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint + b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint value = tstr / binary-value / numeric / bool numeric = number / decfrac Figure 1: Common CDDL specification for CBOR and JSON SenML For JSON, we use text labels and base64url-encoded binary data (Figure 2). bver = "bver" n = "n" s = "s" @@ -1139,20 +1141,22 @@ | W/m2 | watt per square meter (irradiance) | float | RFC-AAAA | | cd/m2 | candela per square meter | float | RFC-AAAA | | | (luminance) | | | | bit | bit (information content) | float | RFC-AAAA | | bit/s | bit per second (data rate) | float | RFC-AAAA | | lat | degrees latitude (note 2) | float | RFC-AAAA | | lon | degrees longitude (note 2) | float | RFC-AAAA | | pH | pH value (acidity; logarithmic | float | RFC-AAAA | | | quantity) | | | | dB | decibel (logarithmic quantity) | float | RFC-AAAA | + | dBW | decibel relative to 1 W (power | float | RFC-AAAA | + | | level) | | | | Bspl | bel (sound pressure level; | float | RFC-AAAA | | | logarithmic quantity)* | | | | count | 1 (counter value) | float | RFC-AAAA | | / | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | | | note 1) | | | | % | 1 (Ratio e.g., value of a switch, | float | RFC-AAAA | | | note 1)* | | | | %RH | Percentage (Relative Humidity) | float | RFC-AAAA | | %EL | Percentage (remaining battery | float | RFC-AAAA | | | energy level) | | | @@ -1894,21 +1898,21 @@ [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, + IANA Considerations Section in RFCs", 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, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, @@ -2005,21 +2009,21 @@ 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\"}", + "l":"[{\"href\":\"humidity\",\"foo\":\"bar\"}]", "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