Subject: [core] SenML more-units indication

From: Ari Keränen <[email-masked]>
Date: Fri, 22 Nov 2019 03:54:52 +0000

CoRE WG,

In the previous CoRE WG session we discussed the SenML more units draft [1] and how to (and should you) indicate in SenML Records that scaled units (e.g., km/h) are used instead of the "canonical units" (e.g., m/s).

As Cullen pointed out, this information is needed in SenML data pipeline systems that are based on the assumption that a single unit is used for all measurements of certain type (which is the case for unit registry policy of RFC8428). For example, if the measurement is about speed, you would always use "m/s". Using the same unit consistently enables efficient dispatching and filtering of SenML data records based on the unit alone. You can for example direct all measurements about speed or temperature to an analytics system that does not care about other types of measurements. And you would not need to know the sensor identities beforehand since the unit field contains enough information to do the data routing.

Without any indication, if both scaled and canonical units are used in the unit field, this kind of filtering/dispatching node would not know if the data records can be safely ignored ("this is not about speed") since new units for speed can be registered at any time. With the indication the node could at least raise an exception ("this might have been for me; but I don't know") or perhaps forward the data to another system that is able to deal with scaled units.

After the meeting Cullen and I discussed options for indicating this information (SenML versions, generic capability indications, separate field for different units ("u2"), indicating scaling factor in the records, etc.) and concluded that the best approach seems to be to have a flag in the unit field itself. For example, asterisk before the unit identifier (e.g., "*km/h"), as Carsten briefly suggested in the previous session.

This adds one byte of overhead, which is probably not a big issue in practice. However, given that the need for the indication is non-trivial (see above), the use of the flag with the unit might be surprising for developers and users (especially if you happen to consider it as part of the unit, not a flag) and hence break the principle of least astonishment. And as some of you commented already, this does not look very elegant.

In the CoRE session today we'd like to get a way forward decided with this. If you can think of a better solution, please let us know. If you have more considerations for having or not having such indication, please let us know too.

Thanks,
Ari

[1] https://tools.ietf.org/html/draft-ietf-core-senml-more-units-03