Name, version and date of the document : OMA-TS-LightweightM2M_Core-V1_2-20201110-A
Section of the document : 7-4-6-0-746-SenML-JSON
As written, the specification leads to believe that the use case for SenML timestamped values is limited to stored notifications:
which allows for multiple versions of representations to be sent in the same payload
Historical version of notifications are typically generated when "Notification Storing When Disabled or Offline" resource of the LwM2M Server Object is set to true
which leads to interoperability issues as some implementations assume that it doesn't make sense to receive SenML timestamped values from arbitrary operations (ex.: ReadResponse, Send) and entirely reject those.
I believe it would make sense to extend the use cases to address the need to precisely timestamp values, not only store notifications.
As written, the specification leads to believe that the use case for SenML timestamped values is limited to stored notifications:
which leads to interoperability issues as some implementations assume that it doesn't make sense to receive SenML timestamped values from arbitrary operations (ex.: ReadResponse, Send) and entirely reject those.
I believe it would make sense to extend the use cases to address the need to precisely timestamp values, not only store notifications.