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

[Carsten Bormann <[e-mail]>]

Hi Benjamin,

it took us a while to better understand the concern and come up with text.

We have now submitted -04:
https://tools.ietf.org/html/draft-ietf-core-multipart-ct-04
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-multipart-ct-04.txt

> On May 5, 2019, at 01:21, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Thu, May 02, 2019 at 03:11:25PM +0200, Carsten Bormann wrote:
>> 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.
> 
> I think that analogies to multipart/mixed and/or multipart/alternative
> would help the reviewer assess whether the document text succeeds at
> describing the intended behavior (though it's not clear that using such a
> reference to attempt to define the behavior by reference is a useful plan).

Please have a look at what we did — we made it more explicit that the semantics are indeed refined by the request context, but that multipart/mixed is our model here and multipart/alternative is outside the range that this media type addresses.

>> 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.
> 
> So while this may not be quite multipart/alternative, there are still
> alternatives involved; they are just delievered in separate (streamed)
> responses, as opposed to together in the same one.  That is, the
> alternation is over time and not at the choice of the recipient.

Multipart/alternative is recipient choice; scenario 3 is originator choice.
The need for the “union type” alluded to in the introduction may be idiosyncratic to CoAP: We expect an observed resource to go through states that all can be described by representations of the same content type.  Maybe that was not such a smart expectation, but the union type mechanism allows us to paper over that.  In any case, there is no “order” or “choice” problem in this scenario.

>> 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.
> 
> I think it's important to be clear about whether the sequencing within a
> given content array is or is not semantically relevant,

This is very much a function of the semantics that the request had on the resource.  If you get a mail with multipart/mixed in it, is it semantically relevant that the service manual is first, then the user manual next among the attachments?
The ordering may simply be alphabetic by name (and that may actually be what the request originally said).

> and under what
> conditions a recipient might only consult a subset of the array
> (multipart/alternative) vs. assembling a conglomerate from components of
> different types (multipart/mixed).

That is now addressed.  

Grüße, Carsten