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

[Carsten Bormann <[e-mail]>]

Let me try to add my personal view to this.

In the Web, we have a lot of places where we put things into a sequence, without being too specific about what the semantics of that sequence is.

E.g., if I ask for a directory listing in a Web browser, I get a bag (collection) of file entries, each represented by a file name, other metadata, and a link.  This is not a multipart body, but is just structured as HTML (and actually could include the linked content via data URIs).

But actually, most directory listers allow me to ask for a specific sequence, e.g. newest first or alphabetic by filename.  There is nothing in the media type I get back that would explain the chosen semantics, it is just context from what I clicked on (i.e., the URL in a link put on table heads).  So once I click on “Date”, I expect the sequence to be by change time.  (Really nice listers will then tell you so by a little triangle in the header, but it works without that.)  

Multipart-core is a similar thing: The basic semantics of the sequence is a bag (collection), but the context might provide some more specific semantics that depends on the order in the sequence.

Early in the life of this draft we thought we might put this under the multipart top-level media type.  That actually provides multiple semantics (alternative, mixed, …) as subtypes.  But the multipart top-level also would have tied us to the MIME multipart syntax.  So we moved this to the application catch-all top-level, probably not quite in the intent of RFC 2046 (which distinguishes discrete and composite media types).  We also didn’t see much use for multiple subtypes with different semantics, so we settled for one media type name: application/multipart-core.
(To Mirja’s question: Why is it “core"?  CoRE is the abbreviation for “constrained RESTful environments” and expresses that the area of use is constrained environments and thus the syntax we chose is optimized for that.  If we had wanted to introduce a separate top-level with multiple subtypes, that could have been called multipart-core/… as well.)

Grüße, Carsten


> On Jul 3, 2019, at 11:08, Thomas Fossati <[e-mail]> wrote:
> 
> Hi Ben, Alexey,
> 
> First, apologies for taking so long to reply.
> 
> Second, I am not sure I agree with the core of Ben's DISCUSS.  Here's my
> reflections:
> 
> The aim of this is to define a (very) flexible container type capable of
> expressing things like - borrowing from ASN.1 - SEQUENCE, SEQUENCE OF,
> SET, SET OF, CHOICE and ANY in a simple and uniform way.
> 
> The main point is it's up to the application that uses multipart-core
> to define a) the flavour of aggregation and b) what the embedded
> representations mean (see for example [1]) - which, incidentally, is
> also what allows the spec to be so compact & lightweight.
> 
> Personally, I think that trying to specialise the container semantics (a
> la mixed / alternative / parallel) is a complication that doesn't add
> much value.  (Pardon the bluntness, but it seems to me that mimicking
> the email application model in this context is a rather futile exercise
> in coherency.)
> 
> Deciding to not restrict the aggregation semantics - at least for me -
> is a precise design choice.  Note however that we leave the door open
> to future or application-specific refinements of the aggregation via
> content-format override (see last para of [2]).
> 
> Cheers, thanks!
> 
> [1] https://tools.ietf.org/html/draft-ietf-ace-coap-est-12#section-5.3
> [2] https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03#section-1
> 
> On 05/05/2019, 00:22, "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).
> 
>> 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.
> 
>> 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, 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).
> 
>    -Ben
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
>