Subject: [core] Fwd: New Version Notification for draft-jennings-core-senml-00.txt

From: Zach Shelby <[email-masked]>
Date: Thu, 13 Nov 2014 00:17:26 +0000

This is a refresh of the SenML draft, attaching it to the CoRE WG and making minimal updates only. The plan is to work on already known improvements such as a CBOR serialisation and nesting support.

Zach

Begin forwarded message:

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-jennings-core-senml-00.txt
Date: November 12, 2014 2:14:21 PM HST
To: Jari Arkko <[email-masked]<mailto:[email-masked]>>, Zach Shelby <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Zach Shelby <[email-masked]<mailto:[email-masked]>>, Jari Arkko <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-jennings-core-senml-00.txt
has been successfully submitted by Zach Shelby and posted to the
IETF repository.

Name: draft-jennings-core-senml
Revision: 00
Title: Media Types for Sensor Markup Language (SENML)
Document date: 2014-11-12
Group: Individual Submission
Pages: 24
URL:            http://www.ietf.org/internet-drafts/draft-jennings-core-senml-00.txt
Status:         https://datatracker.ietf.org/doc/draft-jennings-core-senml/
Htmlized:       http://tools.ietf.org/html/draft-jennings-core-senml-00

Abstract:
  This specification defines media types for representing simple sensor
  measurements and device parameters in the Sensor Markup Language
  (SenML).  Representations are defined in JavaScript Object Notation
  (JSON), 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 HTTP or CoAP to transport the measurements of the
  sensor or to be configured.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com<http://www.arm.com>
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/<http://fi.linkedin.com/in/zachshelby/>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

---

From: Rene Hummen <[email-masked]>
Date: Fri, 14 Nov 2014 05:08:57 +0000

Hi Zach,

glad to see this pick up pace again.

We have been using SenML in one of our joint projects with industry (use case: industrial monitoring). We pretty much implemented the spec 1:1 and just needed to change the semantics of “bt” and “t” from seconds to milliseconds. This is because the readings from the industrial controller (i.e., the machine) occasionally needed to be taken in sub-second intervals. To still be able to differentiate between measurements within the same time interval, we decided to move to a millisecond granularity. I think it would be worth integrating this as an (optional) encoding into the draft as it could potentially be useful for others as well.

Moreover, I believe it would be worth hinting at "XMLsec" and JOSE for object security in the context of SenML. We actually employ JOSE in our project and it integrates nicely with SenML.

BR
René

On 13 Nov 2014, at 01:17, Zach Shelby <[email-masked]> wrote:

>> From: "[email-masked]" <[email-masked]>
>> To: Jari Arkko <[email-masked]>, Zach Shelby <[email-masked]>, Cullen Jennings <[email-masked]>, Cullen Jennings <[email-masked]>, Zach Shelby <[email-masked]>, Jari Arkko <[email-masked]>
>> 
>> 
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
> 
> Zach Shelby
> www.arm.com
> LinkedIn: fi.linkedin.com/in/zachshelby/
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Nov 2014 19:24:25 -1000

Hi René.

Hi René,

would your use case have benefitted from the use of floating-point numbers?

Grüße, Carsten

> On 13 Nov 2014, at 19:08, Rene Hummen <[email-masked]> wrote:
> 
> Hi Zach,
>

---

From: Rene Hummen <[email-masked]>
Date: Sat, 15 Nov 2014 02:31:09 +0000

Hi Carsten, 

interesting idea. From a serialization perspective, this would certainly be fine for us. I am not sure if the E notation could be cause for trouble though...

René

---

From: Rene Hummen <[email-masked]>
Date: Sat, 15 Nov 2014 04:37:57 +0000

Just as a clarification: I am saying that “bt" and “t” should be in decimal form and that the use of the scientific notation should probably be discouraged when following your suggestion.

René

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 19:28:10 -1000

> Just as a clarification: I am saying that “bt" and “t” should be in decimal form and that the use of the scientific notation should probably be discouraged when following your suggestion.

JSON allows all three of NR1 (decimal integer), NR2 (decimal fraction with decimal point), NR3 (NR1 or NR2 plus a possibly signed decimal exponent); there is no way to selectively disable one of the formats.  (Of course, you can make the semantic constraint that a number is supposed to be integer, but all four of 1, 1.0, 1e0, 0.1e1 are integers.)

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 18 Nov 2014 09:50:44 +0100

Rene Hummen wrote:
> We pretty much implemented the spec 1:1 and just needed to change the
> semantics of “bt” and “t” from seconds to milliseconds.

Carsten Bormann wrote:
> JSON allows all three of NR1 (decimal integer), NR2 (decimal fraction
> with decimal point), NR3 (NR1 or NR2 plus a possibly signed decimal
> exponent); there is no way to selectively disable one of the formats.
> (Of course, you can make the semantic constraint that a number is
> supposed to be integer, but all four of 1, 1.0, 1e0, 0.1e1 are
> integers.)

We've been using SenML in different applications for some time as well,
and also needed sub-second resolution. (Partly because of strict timing
requirements, partly in order to recognize atomic readings of related
sensors).

Our implenentations are using t/bt with its original semantics, with
float processing on big nodes and decimal fixed point on small ones (ie.
a uint64 of milliseconds). We've only encountered NR1/2 which is pretty
straightforward to implement in decimal fixed point; that should be
simple to extend to NR3 even in constrained environments.

Due to the nature of floating point, this has led to some confusion over
pseudo-duplicate values: The same data point fetched in two different
passes won't have equal bt+t values, resulting in need for actual
deduplication (ie. t*(1+-epsilon) cutoffs).

Would a suggestion to SenML users to calculate time deltas in integer
with millisecond resolution work for you, or would you rather switch
semantics to ms completely then?

Any other ideas on how to a) distinguish states in time with both b) the
precision flexibility of floating times and c) the possibility to use it
without floating point operations?

Best regards
Christian Amsüss

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Andrew Mcgregor <[email-masked]>
Date: Mon, 24 Nov 2014 09:50:52 +1100

Express it as a rational, ratio of two integers.  That would let you run
the implementation in milliseconds and have a fixed divisor of 1000... no
floating point or fixed point generation or parsing required, just integers.

It would also work to split out the exponent of a floating point time, so
55 milliseconds would be represented as [55, -3].

But thinking aloud... actually probably the best representation is [count,
frequency], where frequency is the nominal clock rate.  That would let the
very common situation of a 32768Hz watch crystal be represented exactly
with no loss of information.

To allow for much longer time intervals with limited range integers, one
could use a list of pairs [[count, wrap], ... [count, frequency]] so that
you could represent 1 minute, 1 second and 1 tick of 32.768kHz as
[[1,60],[1,32768],[1,32768]]

More compactly, adopting the convention that the list is [years, months,
days, hours, minutes, seconds, count, frequency] and can be truncated on
the left could work, which would make the previous example just
[1,1,1,32768].

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 24 Nov 2014 22:12:04 +0100

> 55 milliseconds would be represented as [55, -3].

Given that parsing both this and e-notatation requires either a
full-fledged JSON parser or a dedicated microparser that handles just
the expected case, I don't see much advantage of writing [55, -3]
instead of 0.055. (My nodes parse the latter, it's not really
complicated). Decimal notation is easier to read, and high-level
software can just use the numerics that come out of their JSON parser.
The only advantage I see in the [] notation is that high-level
implementations are forced to implement their own arithmetics -- that's
nice from the deduplication point of view, but not too readable and not
very nice to implementations that are ok with using float.

> But thinking aloud... [...], adopting the convention that the list is
> [years, months, days, hours, minutes, seconds, count, frequency] and
> can be truncated on the left could work, which would make the previous
> example just [1,1,1,32768].

Using declared ticks is IMO too close to hardware for what SenML tries
to achieve. Most sensor readings that come in arrive in non-decimal
scales as well, and are converted to SI units. (We might use an exchange
format that represents a temperature as [124,256,-20,40] (or passes the
tail of that list via .well-known/core) for a temperature that has the
value of 124 on a scale from 0 to 256 that spans linearly from -20°C to
40°C, but that wouldn't be SenML any more -- it is balanced too far
towards the needs of the embedded nodes, to the extent that they can't
compare values among each other without the help of a powerful central
node). I'd say that as long as we can afford calculating an SI sensor
value on an embedded node (in typical cases, that's a single 32bit
multiplication), we can afford calculating one millisecond time per
measurement as well.  (Depending on implementation, that may require a
64bit multiplication, but that's usually handlable on ultra low power
devices too).

I think it is reasonable to stick with a (possible floating-point)
notation of time in seconds, or integer sub-seconds. I'd rather have an
established way of establishing identity on those time stamps (and the
resulting resource representations conveyed by the SenML document),
either by prescribing a precision for all calculations or by having it
somehow negotiated.

While we're at it, I think it'd be worth considering adding a timestamp
CoAP option as well (for documents that are queried as plain-text but
still want to transfer the information available in SenML), but that's
an issue for another thread and is probably easier once we've sorted
this here out.

Best regards
Christian