Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format
Extracted elements (16)
Both CoAP Content-Format numbers and Content-Format-Strings use a string value in the 'ct' field to keep the data type consistent across uses. When 'ct' contains only digits, it is interpreted as a CoAP Content-Format number, providing a simple disambiguation rule.
Content-Format-Strings are allowed in addition to CoAP Content-Format numbers because some Internet media types and their content coding/parameter combinations do not have assigned CoAP Content-Format numbers. This avoids requiring CoAP registry coverage as a prerequisite.
SenML packs may be propagated over time and via multiple entities, so the creator cannot assume shared out-of-band context with all consumers. Inline content format indication enables automatic interpretation without requiring prior negotiation or contextual knowledge.
The design guarantees that a recipient implementation knows when it needs to be updated to understand field values; registries are used to evolve name spaces in a controlled way, and SenML Packs can be processed by a consumer while not understanding all the information in them.
The document deliberately does not define a mandatory-to-implement version of the fields (as suggested by Klaus Hartke), keeping the specification simple and avoiding the complexity of versioning requirements.
The 'ct' field's CoAP Content-Format number is similar to the 'ct' attribute defined in Section 7.2.1 of RFC 7252 for CoRE Link Format (RFC 6690), representing an unsigned integer in the range 0–65535. All registered numbers are listed in the 'CoAP Content-Formats' registry.
The registry structure for CoAP Content-Formats currently provides for zero or one content coding. Nothing in this document needs to change if the registry is extended to allow sequences of content codings, since the Content-Format-String syntax already supports multiple '@'-separated codings.
When a SenML Record contains a Data Value field ('vd'), the Record MAY also include a Content-Format indication field using label 'ct'. The value must be a Content-Format-Spec (a CoAP Content-Format number or a Content-Format-String).
A Content-Format-Spec is either a Content-Format-Number (a CoAP Content-Format number 0–65535 in decimal with no leading zeros, except '0' itself) or a Content-Format-String (a Content-Type optionally followed by one or more content codings separated by '@' signs).
The ABNF grammar defines Content-Format-Spec as either a Content-Format-Number or Content-Format-String. Content-Format-String is Content-Type followed by zero or more ('@' Content-Coding) segments. The grammar is adapted from RFC 9110, RFC 6838, RFC 5234, and RFC 8866.
The 'bct' (Base Content-Format) field provides a default value for the 'ct' field within its range, covering the Record containing it and all subsequent Records up to (but not including) the next 'bct' field or end of Pack. Resolution adds 'ct' to all Records in range that carry 'vd' but lack 'ct'.
The 'ct' (Content-Format) field may be included in a SenML Record that contains a Data Value field ('vd') to indicate the content format of that binary data. Its value is a Content-Format-Spec: either a CoAP Content-Format number in decimal or a Content-Format-String.
IANA has assigned two new labels in the 'SenML Labels' subregistry of the 'Sensor Measurement Lists (SenML)' registry: 'bct' (Base Content-Format, JSON/XML type: String) and 'ct' (Content-Format, JSON/XML type: String), both referencing RFC 9193. No CBOR labels or EXI schemaId values are assigned.
The indication of a media type in SenML data does not exempt a consuming application from properly checking its inputs. An attacker who can supply crafted SenML data specifying attacker-chosen media types may expose vulnerabilities of handlers for those types, including 'decompression bombs' (compressed data crafted to decompress to extremely large items).
Content codings in a Content-Format-String are appended to the Content-Type value separated by '@' signs, in the order they were applied (same as HTTP Content-Encoding order). For example: 'text/plain; charset=utf-8@deflate'.
The 'ct' field is a string type in both JSON and XML SenML representations. A CoAP Content-Format number is encoded as a decimal string with no leading zeros. Content-Format-Strings use the form 'type/subtype[;params][@coding]*'.