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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Sep 2019 22:32:00 -0500

On Tue, Aug 27, 2019 at 09:43:55PM +0200, Carsten Bormann wrote:
> 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.

I don't disagree with any of what you say.  I'm currently coming at this
from a perspective of "there's a mismatch between what's being described as
use cases and what's being cited for how it works" (a progression from the
previous "this doesn't say precisely what it means, whether directly or by
reference").  Alexey's followups seem to suggest that the issue is just
that the thing "being cited for how it works" (i.e., traditional
multipart/mixed) doesn't quite reflect reality, in which case it seems
fairly straightforward to just note the disparity/divergence-from-reference
and move on.

-Ben

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 23 Sep 2019 15:37:39 +0100

Hi all,
To get closure on this:

> fairly straightforward to just note the disparity/divergence-from-reference

I suggest to do the following change in the 3rd paragraph of the introduction:

   As the name of the media-type suggests, it is inspired by the
   multipart media types that started to be defined with the original
   set of MIME specifications [RFC2046].  However, while those needed to
   focus on the syntactic aspects of integrating multiple
   representations into one e-mail, transfer protocols providing full
   data transparency such as CoAP as well as readily available encoding
   formats such as the Concise Binary Object Representation (CBOR)
   [RFC7049] shift the focus towards the intended use of the combined
   representations.  In this respect, the basic intent of the
   application/multipart-core media type is like that of multipart/mixed
   (Section 5.1.3 of [RFC2046]). 

I suggest changing the last sentence of the above quoted text to read:

   In this respect, the basic intent of the
   application/multipart-core media type is like that of multipart/mixed
   (Section 5.1.3 of [RFC2046]), however the semantics is relaxed to
   allow for both ordered and unordered collections of media types.

If you think this needs to be explained further, something like the following
can be added after that or inserted as a "historic note":

   Experience with multipart/mixed in email has shown that recipients
   that care about order of included body parts will process them
   in the order they are listed inside multipart/mixed and recipients
   that don't care about the order will ignore it anyway. multipart/parallel
   that was intended for unordered collections didn't deploy.

Does this work for people?

Thank you,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Sep 2019 09:45:07 -0700

> Does this work for people?

Both the "short version" and the "long version" look great to me.

Thanks,

Ben

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 23 Sep 2019 17:52:35 +0100

Hi Benjamin,
I've added the long version as an RFC Editor note. If you can clear your DISCUSS, that would be much appreciated!

Thank you,
Alexey

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Sep 2019 19:10:27 +0200

> Does this work for people?

Works great for me, in particular the version now at https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/writeup/ — thank you for coming up with this.

I tend to misread the sentence starting with the lower case media type name.  Maybe that stumbling stone can be defused by changing the start of the sentence to:

The media type multipart/parallel

Grüße, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Sep 2019 18:37:34 +0100

> On 23 Sep 2019, at 18:10, Carsten Bormann <[email-masked]> wrote:
> 

Done.