Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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?
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.
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."
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/
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...
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.
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
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 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.