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

From: Christian Amsüss <[email-masked]>
Date: Wed, 7 Jan 2015 20:12:25 +0100

Over the last weeks I've stumbled on two further points that seem
noteworthy to me in this yet discussion:

Timestamps in CBOR: CBOR (which for some reasons until recently went
below my radar) requires floating point numbers to be encoded as such,
there is no support for decimal floating point, so using milliseconds
internally and presenting them as pseudofloats is not really an option
as CBOR support is planned for SenML.

Given that, choosing milliseconds as time base units looks more
promising to me again. Then again, whoever uses CBOR will also have to
deal with SI valued sensor values (which just as well can come along as
decimal values, think voltage readings as mV) vs floating point numbers.

On Mon, Nov 24, 2014 at 10:12:04PM +0100, Christian Amsüss wrote:
> 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.

Potential CoAP timestamp option: It should be considered that HTTP's
http-date headers (Date, Last-Modified) do not cater for sub-second
precision at all.

Best regards
Christian

-- 
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: Carsten Bormann <[email-masked]>
Date: Thu, 08 Jan 2015 08:14:26 +0100

> as CBOR support is planned for SenML.

While RFC 7049 defines tag 1 for fixnums, bignums, or floats, there is
no need to limit ourselves to tag 1.  So we could just define another
tag that takes a decimal floating point (or we could even combine the
two tags into one).  (Or we could *change* tag 1 to allow decimal [and
binary?] fractions as well.  Or we could not use tags at all and make
this part of the semantics of some map key.  Some bikeshedding is
possible here.)

> decimal values, think voltage readings as mV) vs floating point numbers.

Right.  So the question that pops up and requires some research is, how
much in sensor data is naturally in decimal fractions of base SI units.
Certainly scales measure in grams and milligrams, and centi-Kelvin is
one way to express a temperature.  But I don't really have a
quantitative view of the bigger picture here.

> http-date headers (Date, Last-Modified) do not cater for sub-second

Depending on who you talk to, this either doesn't matter (because
timestamps are about expiry and that is fine enough on a second
boundary) or it is a long-standing known limitation of HTTP.

I'm not sure I like the premise of stuffing certain parts of the body
into options, though.  I'd rather address the "structured
representation" issue head on.

Gruesse, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 9 Jan 2015 11:34:07 +0100

Hallo Carsten,

> this part of the semantics of some map key.  Some bikeshedding is

I've got to admit I skipped over the bigfloats section as it didn't seem
applicable, but actually, bigfloats and decimal fractions are exactly
what was discussed before -- sorry I incorrectly claimed that the latter
were unsupported.

If we somehow allow millisecond users to encode 4.567 seconds to
1(4([-3,4567])) (that is "an epoch-based timestamp [here: time delta]
constructed from the decimal fraction 4567*10**-3", or similar if it's
easier to have a new tag instead of extending the existing one), this
should make users of all time formats happy.

Users of 1024th seconds or similar might still want to use major-type 7
floats instead of bigfloats, but as long as they only encode, this
should be a compressison step that can be done for the common cases in a
few lines of code (which, given the known input ranges, would not even
have to deal with denormalized numbers, and thus stay out of the more
complex parts of IEEE float representation).

The example above got me to wonder: Would tag 1 be at all applicable to
SenML's "t" field, given it can either mean epoch time values, or deltas
to a "bt" epoch time, or even mean "some time in the past"?

> quantitative view of the bigger picture here.

I've looked around some widespread (as measured by cheapness or search
engine results) for temperature, air humidity, flow and acceleration,
and found that decimal units seem to be rare; units are much more often
binary or need formula evaluation. Those formulas often have their
coefficients given in decimal, which leads to units like centi-degC, but
those calculations can be done in binary as well without exceeding the
device's accuracy limits.

(Originally I wanted to survey more devices than the dozen I did, after
reviewing what can be done with decimal fractions and which parts of
IEEE floats are actually needed, I don't see that issue as pressing any
more, and think that we're good with the units in
draft-jennings-core-senml-00).

> representation" issue head on.

I don't think we can push all the metadata off into a structured
representation, but at least as with CBOR one can encapsulate even
binary data in SenML, the time issue is not that pressing any more.

It seems to me that there is only one open point from this discussion
with respect to CBOR, that is, how do we best allow decimal fractions in
timestamps (I'd favor allowing it for tag 1 but am not sure of the
implications RFC-wise), and whether tag 1 is OK for time deltas.
Carsten, what are your opinions on those?

With respect to SenML encoding, there remains the question of which
serializations should be allowed. My opinion is that once you start
writing a JSON parser, supporting both decimal point and e notation does
not consume that much more resources to justify requiring SenML
serializers to force their JSON serializers into a particular format.

Best regards
Christian