Multipart Content-Format for the Constrained Application Protocol (CoAP)
RFC 8710

A few minor nits/points:

(1) Section 1.  Grammar Nit.

s/This specification allows to indicate that/
This specification allows one to indication that/

(2) Section 1.  Per “A third situation that is common only ever has a single representation in the sequence, which is one of a set of formats possible”, it isn’t clear to me what the dependent clause, “which is one of the a set of formats”, is suggesting.  If there is only a single representation, how is there a “union of formats” as suggested by the follow-on sentence?

(3) Section 2.  The provided example of two representations is helpful.  It would be useful to carry this example through and use it again in Implementation Hints section.

(4) Section 2.  Per “(This generally means the representation is not processes at all except if some stream processing has already happened.)”, the target of this observation isn’t clear to me – perhaps the third clause from the previous sentence about left over data?

(5) Section 4.  Nits.  Make the section title case, like the other sections.

s/Implementation hints/Implementation Hints/

Thank you to the authors for their work. Short and clear document, I have appreciated the example of CBOR encoding.

== comments ==

In section 2, I wonder the error in CBOR decoding: should it stop or completely ignore all parts of the message? Is there any use case where decoding only part of the messsage causes problem?


== nits ==

section 2, s/ specification: An/ specification: an/  ?

Thanks for the work everyone put in on this document.

The "Usage Examples" section seems a bit odd, since it only describes the use of
this new content type for sending a response prior to the response body becoming
available. The introduction does not give the impression that this is the
primary use case -- it implies that this new format is primarily intended to
be used in a similar fashion as the traditional multipart/* media types.
Perhaps there should be some additional examples in section 3 that outline these
more common cases?

Alternately, if I have misunderstood the primary use case for this mechanism,
then I would humbly offer that the introduction needs substantial revision.

Please respond to the Gen-ART review.

= Section 2 =

"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."

I think it would be more precise to refer to the "even-numbered elements" and the "odd-numbered elements" rather than enumerating the elements and saying "etc."

Thank you for addressing my Discuss point!

Thanks for the rapid response. I am happy to clear. However, I think it would be good to be explict about that nesting is allowed in the definition even if the formal language implies it.

I guess
0x82 0x00 0x4b H e l l o 0x20 w o r l d 
should be
0x82 0x00 0x4b H e l l o 0x20 W o r l d

One minor question: I don't fully understand why the new content format is called "application/multipart-core". Does "core" stand for the core working group? Shouldn't it rather be "application/multipart-coap"? Also why "multipart" and not e.g. "multicontent"? I guess it doesn't matter that much but was mainly wondering where the naming came from...