Multipart Content-Format for the Constrained Application Protocol (CoAP)
Extracted elements (15)
A zero-length array (empty multipart-core) is used to represent the absence of any representation in a 'union type' scenario, where the sender selects one from a set of possible formats but chooses none. This avoids a special-purpose null response code.
Fragment identifier syntax and semantics for application/multipart-core are defined to follow those of application/cbor; at publication time no fragment identification syntax was defined for application/cbor, effectively leaving fragmentation undefined.
The multipart/parallel MIME type intended for unordered collections was not widely deployed in email, so application/multipart-core relaxes ordering semantics to allow both ordered and unordered collections rather than splitting into separate types.
The use of CBOR rather than a MIME-style textual framing was chosen because CoAP provides full data transparency and CBOR is a readily available binary encoding, shifting focus from syntactic framing to semantic intent of the combined representations.
When combining application/multipart-core with CoAP Observe (RFC 7641), the Observe option requires all notifications to carry the same Content-Format. The multipart-core type can serve as a stable Content-Format envelope, carrying an empty list for pending results and a single-element list once the resource becomes available.
An implementation MUST stop processing the representation if there is a CBOR well-formedness error, a deviation from the defined structure, or any residual data left after processing the CBOR data item.
A null value may substitute for the byte string representation of an optional part, indicating that the part is not present. This allows senders to signal the absence of an optional component without omitting the Content-Format slot.
An application/multipart-core representation carrying no representations is encoded as an empty CBOR array, serialized as the single byte 0x80.
The Content-Format type field in each multipart-part is an unsigned integer of size 2 (uint .size 2), and the part is either a byte string or null. The CDDL definition is: multipart-core = [* multipart-part]; multipart-part = (type: uint .size 2, part: bytes / null).
IANA registered Content-Format ID 62 for application/multipart-core (no encoding) in the 'CoAP Content-Formats' subregistry within the 'Constrained RESTful Environments (CoRE) Parameters' registry.
IANA registered the media type application/multipart-core under the 'application' type tree, with binary encoding considerations and no required or optional parameters.
The security considerations of RFC 7049 (CBOR) apply. Resource exhaustion attacks may employ large values for byte string size fields or deeply nested structures of recursively embedded application/multipart-core representations.
Content-Format IDs are serialized as CBOR unsigned integers: 0x00–0x17 for values 0–23 (1 byte), 0x18 0xnn for 24–255 (2 bytes), and 0x19 0xnn 0xnn for 256–65535 (3 bytes).
Object (byte string) lengths are serialized as: 0x40–0x57 for lengths 0–23, 0x58 0xnn for 24–255, 0x59 0xnn 0xnn for 256–65535, 0x5a 0xnn 0xnn 0xnn 0xnn for 65536–4294967295, and 0x5b followed by 8 bytes for larger lengths.
The application/multipart-core representation is encoded as a CBOR array with an even number of elements. Even-indexed elements are unsigned integers specifying the Content-Format ID; odd-indexed elements are byte strings containing the representation or null if the optional part is absent.