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

[Carsten Bormann <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Wed, Aug 21, 2019 at 09:37:10PM +0200, Carsten Bormann wrote:
>> 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
> 
> [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
> 
> 
>>> 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
>> 
>