Multipart Content-Format for CoAP
draft-ietf-core-multipart-ct-04

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Benjamin Kaduk Discuss

Discuss (2019-05-01 for -03)
It's not clear to me that we're really specifying the semantics of a
single media-type.  The introduction discusses how we may want multiple
representations to appear in a sequence, potentially representing
different content.  Or we may have a set of related representations that
conceptually are the same content (but are they literally the same
resource, or related content?).  And there is yet a third option -- one
that I'm not sure I fully understand -- wherein the representation is
not important, but rather which format is chosen of the several
possibilities, to the extent that extreme compression of the
representation is possible, with the compression just outputting the
format indicator.

I don't see that any of these three cases are mutually compatible with
each other -- are we not defining three different semantical
representations that share a common syntax?  How does a receiver know
which semantics to apply, if they share a common media-type codepoint?
Comment (2019-05-01 for -03)
The security considerations seem incomplete, at least given my
understanding of the intended technical semantics for the media-type.
Specifically, there is no discussion of how the recipient chooses which
semantics to apply (and the risks of choosing incorrectly), or
discussion of the latent risk when there are supposed to be multiple
equivalent or related components but that's not validated or the
recipient only acts on part of the data.

Barry Leiba Yes

Alexey Melnikov Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2019-04-30 for -03)
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."

Roman Danyliw No Objection

Comment (2019-04-24 for -03)
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/

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2019-04-29 for -03)
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...

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2019-04-29 for -03)
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.

Martin Vigoureux No Objection

Comment (2019-04-29 for -03)
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

Éric Vyncke No Objection

Comment (2019-05-02 for -03)
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/  ?

Magnus Westerlund (was Discuss) No Objection

Comment (2019-05-02 for -03)
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.