Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Alexey,

On May 2, 2019, at 14:40, Alexey Melnikov <[e-mail]> wrote:
> 
> Hi Benjamin,
> 
> On Thu, May 2, 2019, at 1:05 AM, Benjamin Kaduk via Datatracker wrote:
> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> 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.
> 
> I think this is similar to multipart/mixed.

We were indeed trying to follow the model of multipart/mixed.
This offers a number of embedded representations the sequence of which may or may not be important.

>> 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?).
> 
> My understanding is that they are related contents.

There is no promise that the related items are conceptually the same content.
The difference between the first situation and the second one mainly is that the sequence is not important in the second (i.e., we are using the sequence to describe a bag).

>> 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.
> 
> Hmm, I missed that. I think this is similar to multipart/alternative

That wasn’t the intention.
The choice in the third situation mentioned in the introduction is made by the originator of the representation, not the receiver.  The selected representation is still packaged in an application/multipart-core envelope so the media type does not need to diverge — it is essentially used as the (type!) union (a.k.a. choice) of the media types that the application wants to be able to put in the envelope.

We may have painted ourselves into a corner in RFC 7641 with the mandate that the representations provided by an observable resource stay within the same media type (content-format) over time.  This makes it difficult in CoAP to observe a resource that alternates between a “pending” and a “ready” state that have different structures of their representation.  Multipart-core can be used to package either into the same media type.

I don’t think the third situation has semantics that differ from the first two.
You still get a bag with a representation in it (or maybe none).  You still need to look into the bag to see what form it takes this time.  Actually, the second situation might also apply, so you might indeed get a couple representations in certain instances because that’s what best describes the resource at this particular time.

Grüße, Carsten