Draft: draft-ietf-core-multipart-ct

Commentary: Address    outstanding DISCUSS . 
 No : with that , the sender sends along all formats and the recipient chooses based on its capabilities or preferences . Appropriate for single - shot mail , not at all appropriate for a request / response situation ( at least not for the response part ) .  ,    sorry , had n't read properly ( it 's sender , not receiver ) . 
 LGTM
Paragraph (version A):
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 into a single message, such as a
CoAP RFC7252 request or response body, with minimal framing overhead,
each along with a CoAP Content-Format identifier.
Paragraph (version A):
The individual representations in an application/multipart-core 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
different formats to be played out in that sequence.
Paragraph (version A):
In other cases, an application may be more interested in a bag of
representations, which are distinguished by their Content-Format
identifier, 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 allows to
indicate that an optional part is not present by substituting a null
value for the representation of the part.
Paragraph (version A):
A third situation that is common only ever has a single
representation in the sequence, which is one of a set of formats
possible.  This kind of union of formats may also make the presence
of the actual representation optional, the omission of which leads to
a zero-length array.
Paragraph (version A):
Where these rules are not sufficient for an application, it 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
application/multipart-core.
Paragraph (version B):
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 along with a CoAP Content-
Format identifier, into a single representation, with minimal framing
overhead.  This combined representation may then be carried in a
single message, such as a CoAP RFC7252 request or response body.
Paragraph (version B):
The individual representations in an application/multipart-core 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.
Paragraph (version B):
In other cases, an application may be more interested in a bag of
representations, which are distinguished by their Content-Format
identifier, 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.
Paragraph (version B):
A third situation that is common only ever has a single
representation in the sequence, where the sender already 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.
Paragraph (version B):
Where these rules are not sufficient for an application, it 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.
Paragraph (version B):
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 RFC2046), where several alternative representations
are provided in the message, 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).
Paragraph (version A):
The collection is encoded as a CBOR RFC7049 array with an even number
of elements.  The second, fourth, sixth, etc. element is a byte
string containing a representation, or the value "null" if an
optional part is indicated as not given.  The first, third, fifth,
etc. element is an unsigned integer specifying the content format ID
of the representation following it.
Paragraph (version B):
The collection is encoded as a CBOR RFC7049 array with an even number
of elements.  Counting from zero, the odd-numbered elements are a
byte string containing a representation, or the value "null" if an
optional part is indicated as not given.  The (even-numbered) element
preceding each of these is an unsigned integer specifying the content
format ID of the representation following it.
Paragraph (version A):
When a client registers to observe a resource RFC7641 for which no
representation is available yet, the server may send one or more 2.05
(Content) notifications before sending the first actual 2.05
(Content) or 2.03 (Valid) notification.  The possible resulting
sequence of notifications is shown in Figure 1.
Paragraph (version B):
This section illustrates one less obvious example for using
application/multipart-core: combining it with observing a resource
RFC7641 to handle pending results.
Paragraph (version B):
When a client registers to observe a resource for which no
representation is available yet, the server may send one or more 2.05
(Content) notifications before sending the first actual 2.05
(Content) or 2.03 (Valid) notification.  A diagram depicting possible
resulting sequences of notifications, identified by their respective
response code, is shown in fig-sequence.
Paragraph (version B):
where (*) marks the start of the information about the first
representation (content-format 42, byte string length 8) and, (+), of
the second representation (content-format 0, byte string length 5).