This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a CoAP Content-Format identifier [RFC 7252
]) into a single representation, with minimal framing overhead.
This simple and efficient binary framing mechanism can be employed to create application-specific message bodies that build on multiple already existing media types.
As the name of the media type suggests, application/multipart-core was inspired by the multipart media types initially defined in the original set of MIME specifications [RFC 2046
] and later. However, while those needed to focus on the syntactic aspects of integrating multiple representations into one email, transfer protocols providing full data transparency such as CoAP as well as readily available encoding formats such as the Concise Binary Object Representation (CBOR) [RFC 7049
] shift the focus towards the intended use of the combined representations. In this respect, the basic intent of the application/multipart-core media type is like that of multipart/mixed (Section 5.1.3
of RFC 2046
); however, the semantics are relaxed to allow for both ordered and unordered collections of media types.
Historical Note: Experience with multipart/mixed in email has shown that recipients that care about order of included body parts will process them in the order they are listed inside multipart/mixed, and recipients that don't care about the order will ignore it anyway. The media type multipart/parallel that was intended for unordered collections didn't deploy.
The detailed semantics of the representations are refined by the context established by the application in the accompanying request parameters, e.g., the resource URI and any further options (header fields), but three usage scenarios are envisioned:
In one case, the individual representations in an application/multipart-core message body occur in a sequence, which may be employed by an application where such a sequence is natural, e.g., for a number of audio snippets in various formats to be played out in that sequence or search results returned in order of relevance.
In another case, an application may be more interested in a bag of representations (which are distinguished by their Content-Format identifiers), such as an audio snippet and a text representation accompanying it. In such a case, the sequence in which these occur may not be relevant to the application. This specification adds the option of substituting a null value for the representation of an optional part, which indicates that the part is not present.
A third common situation only has a single representation in the sequence, and the sender selects just one of a set of formats possible for this situation. This kind of union "type" of formats may also make the presence of the actual representation optional, the omission of which leads to a zero-length array.
Where these rules are not sufficient, an application might still use the general format defined here but register a new media type and an associated Content-Format identifier to associate the representation with these more specific semantics instead of using the application/multipart-core media type.
Also, future specifications might want to define rough equivalents for other multipart media types with specific semantics not covered by the present specification, such as multipart/alternative (Section 5.1.4
of RFC 2046
), where several alternative representations are provided in the message body, but only one of those is to be selected by the recipient for its use (this is less likely to be useful in a constrained environment that has facilities for pre-flight discovery).