bsilverajan
commented
3 years ago Closing, as the consensus during meetings is not to include this attribute to the draft, but instead employ other ways for supplying historical state representations eg the Series Transfer Pattern (STP) (draft-bormann-t2trg-stp)
OMA LwM2M added support for additional attributes that should be reflected back into the dynlink draft to avoid fragmentation. One of those attributes is called "Maximum Historical Queue".
The current LwM2M Core Spec currently has this statement: "The behaviour of Notification class attributes MUST follow [DynLink] unless stated otherwise in this specification. Note: The attributes epmin, epmax, con and edge are specified in this specification but currently not referenced in [DynLink]."
The goal would be to change that statement to: "The behavior of all Attributes SHOULD follow [DynLink]."
Below is content to consider for the dynlink draft: "The Maximum Historical Queue Attribute indicates how many entries of historical data resulting from an Observation of a specific Object, Object Instance, Resource, Resource Instance MUST be stored, e.g. while the LwM2M Client is offline, or, the LwM2M Server account is disabled. If this attribute is present, only the data of Objects, Object Instances, Resources, Resource Instances with hqmax>0 will be included in notifications which were stored while disabled or offline. Historical notifications MAY be sent in a format as described in Section [SenML JSON] (). If the queue size reaches hqmax and a new reading is received, the oldest reading MUST be dropped. The LwM2M Client SHOULD empty the queue as soon it becomes aware that connectivity has been restored. The use of "hqmax" is dependent on notification storing being enabled via the "Notification Storing When Disabled or Offline" Resource of the LwM2M Server Object."