Sensor Measurement Lists (SenML) Features and Versions
updates
- rfc-8428 — Sensor Measurement Lists (SenML)
Extracted elements (15)
Less generally applicable features need not consume a feature code; they can instead be communicated via must-understand fields (field names ending with '_') as defined in RFC 8428 Section 4.4, preserving feature code space for widely useful capabilities.
Over time, batching related extensions into a single feature bit is preferred over fully independent fine-grained bits, as too many individually selectable optional extensions reduce interoperability. This creates a hybrid between completely independent extensions and a linear version scheme.
The SenML version number is repurposed as a bitmap rather than a linear counter: each bit position (feature code) represents an independently selectable capability feature. This allows a recipient to check exactly which features are required to process a given pack, rather than assuming all lower-numbered versions are subsumed.
The upper limit for feature codes is 52 (codes 4–52 available, 48 remaining after reserved codes) because practical JSON limits safe integer representation to 2^53−1 per RFC 7493. Approximately two feature codes per year or fewer should be allocated to sustain this scheme for several decades.
RFC 8428 Section 4.4 implies version numbers are totally ordered (understanding v=n implies understanding all k<n), which is no longer true. Packs using any feature beyond the reserved 4 bits produce version numbers greater than 10, which RFC 8428 implementations will correctly reject as unknown versions rather than accept with false interoperability.
Implementations that handle feature bits beyond the first four (i.e., version numbers greater than 10) MUST perform a bitwise comparison of the feature bitmap and ensure that all indicated features are understood before using the pack.
Reserved feature codes 0–3 MUST NOT be used with any more specific semantics except in a specification that updates RFC 9100. They may only be reassigned by a future standards document.
The designated IANA expert MUST maintain a frugal regime of code point allocation and ensure feature names are usable as identifiers in most programming languages (after lowercasing and replacing spaces with underscores or hyphens) and are distinct in that form.
When the Secondary Units feature (code 4) is indicated, secondary unit names from RFC 8798 MAY be used in the 'u' field of SenML records in addition to the primary unit names already allowed by RFC 8428.
A SenML Feature is identified by a feature name (text string) and a feature code (unsigned integer less than 53). The 'bver' field (version number) of a SenML pack is the sum of 2^fc for each present feature code fc, forming a feature bitmap.
Feature codes 0–3 are reserved for RFC 8428 base compatibility: Reserved1 (code 1) and Reserved3 (code 3) are always present, while Reserved0 (code 0) and Reserved2 (code 2) are always absent, yielding the base version number 10 (0b1010) when no other feature is set.
The 'Secondary Units' feature (feature code 4) indicates that secondary unit names defined in RFC 8798 MAY be used in the 'u' field of SenML records in addition to primary unit names. Enabling this feature sets the SenML version number to 26 (10 + 2^4).
IANA created a new 'SenML Features' subregistry within the 'Sensor Measurement Lists (SenML)' registry with registration policy 'Specification Required'. Columns are: Feature Code (unsigned integer < 53), Feature Name (text), and Reference. Initial entries are Reserved0–Reserved3 (codes 0–3) and Secondary Units (code 4).
The security considerations of RFC 8428 apply in full. The feature bitmap reinterpretation of the version number introduces no additional security considerations beyond some potential for surprise that version numbers are no longer linearly ordered.
The SenML version number field ('bver') encodes features as a bitmap: version = Σ present(fc) · 2^fc for fc = 0 to 52. It is an unsigned integer with a practical upper bound of 2^53−1 imposed by JSON number representation.