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

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Aug 2019 21:37:10 +0200

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 <[email-masked]> 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 <[email-masked]> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Aug 2019 13:18:02 -0500

> https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-multipart-ct-04.txt

[replying at the top since what I am trying to say is essentially wrapping
all the inline notes together]

I can grudgingly accept the decision to focus solely on a multipart/mixed
equivalent, though it remains surpising to me that stopping there is
desired.  That is, my reading of RFC 2046 is that the "mixed" subtype is a
catchall generic container that is usable as a fallback for when a
more-specific subtype is not supported/understood, but that direct use was
somewhat discouraged due to the more rich array of semantics available
(noting that 2046 itself specifies several additional subtypes with the
"more-rich" semantics).  So it's surprising that we stop with the generic
container, and do not mirror RFC 2046 in defining some more-rich subtypes
with precise semantics.

That said, within the context of only specifying a multipart/mixed
analogue, I still think we need to have some further discussion about the
applicability of those semantics to the listed use cases.  RFC 2046 is
quite clear that "mixed" is used when the body parts "need to be bundled in
a particular order".  The first use case listed, for audio snippets to be
played back in sequence or search results, is a natural fit for
multipart/mixed.  The second ("bag of representations"), however, includes
a note that "the sequence in which these occur may not be relevant to the
application", which does not seem like a good fit for multipart/mixed:
depending on the specifics, either multipart/alternative or
multipart/parallel seem to be a better match for the stated semantics.  The
third listed use case (sender-selects from a union) also doesn't feel like
a great fit, since there is mostly just one "inner" type in a give
response, and thus no ordering to be had; even in the (transient?) case
where a resource is represented by multiple of the potential output
formats, it's not clear that the ordering will always be important.  This
use case in particular feels like a very good match for defining a new
subtype with precise, rich, semantics for "sender selects from union".

Finally, I would like to continue to push back on the sense that it is good
to have the surrounding (request) context play a large role in interpreting
the semantics of the response.  While this is of course unavoidable to some
extent, I am not sure that encouraging it is wise.  Consider, for example,
JWT, which is becoming quite popular, but also is having to react to quite
real security threats due to the lack of explicit typing from the start.
The mere fact that I have to ask "can my access token be misused as an
identity token?" seems like a failure of the context-dependent semantics.
Granted, JWT is a cryptographic construct involving a signature from a
trusted authority, which is not the case here, but the general question of
whether we want to place more weight on the two parties communicating
making the same implicit/heuristic-based choices about interpreting content
when we can easily make the semantics more explicit and rely less on all
implementations making the same choices seems to still apply.

Thanks,

Ben

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Aug 2019 21:43:55 +0200

Hi Benjamin,

I completely agree that signed security assertions need to be interpretable without external context.  But that is a very different world from the media type being defined here.

In a CoAP interaction, the response might be (literally)

	33.5

to tell you the temperature in my room.  SenML can be used to include more context, but often the request context is really needed to make sense of the response (here probably something like “GET /temp1”, translated into a CoAP request), and additional information may only be available through the installation context (e.g., that this temperature is in °C and not in °F, or that the above request to [2001:db8::1]:5683 actually leads to the temperature sensor for the room to right of the corridor, second door).

(OSCORE protects the relationship between the request context and the response, but cannot really protect the external context except by relating the key of the server with its function/installation location.  Where the latter is really hard to protect, and then somebody can still come with a lighter and heat up the sensor, leading to incorrect temperature measurements just for fun.)

This is the reason why the ambiguities incurred by using this media type are really on the mild side.

Grüße, Carsten

> On Aug 26, 2019, at 20:18, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Aug 2019 11:39:06 +0100

Hi Ben,

> On 26 Aug 2019, at 19:18, Benjamin Kaduk <[email-masked]> wrote:
> 
> "more-rich" semantics).

Having recently spent many hours coding handling of different multipart/* media types in an email client, I don’t think I agree. Yes, multipart/mixed is the fallback, but I don’t believe that any document discourages its use. Certainly observing multipart/* media types used in the wild, I only ever see multipart/mixed (the most common), multipart/alternative, multipart/related, multipart/report and rarely multipart/digest. multipart/report and multipart/digest have special structure and purposes, I don’t think they are relevant to draft-ietf-core-multipart-ct.

> So it's surprising that we stop with the generic
> multipart/parallel seem to be a better match for the stated semantics.  

As far as I am concerned there is zero use of multipart/parallel in email or web. Even if it was a good idea at the time, the market decided against it.

I think multipart/mixed is used for both as an ordered sequence and as an unordered collection. Considering variety of UIs for handling multipart/mixed, I don’t think the difference matters significantly for people to care about differences between 2 cases.

> The

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Aug 2019 11:46:09 +0100

Hi Ben,

> On 31 Aug 2019, at 11:39, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Ben,
> 

I am ambivalent on this. It doesn’t match the multipart/alternative semantics (this case effectively just has 1 choice) and it is close enough to other cases that I am not convinced that a new media type would be important to implementors.

Best Regards,
Alexey