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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 17:05:40 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-multipart-ct-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/

----------------------------------------------------------------------
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.  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?).  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.

I don't see that any of these three cases are mutually compatible with
each other -- are we not defining three different semantical
representations that share a common syntax?  How does a receiver know
which semantics to apply, if they share a common media-type codepoint?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The security considerations seem incomplete, at least given my
understanding of the intended technical semantics for the media-type.
Specifically, there is no discussion of how the recipient chooses which
semantics to apply (and the risks of choosing incorrectly), or
discussion of the latent risk when there are supposed to be multiple
equivalent or related components but that's not validated or the
recipient only acts on part of the data.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 02 May 2019 08:40:40 -0400

Hi Benjamin,

On Thu, May 2, 2019, at 1:05 AM, Benjamin Kaduk via Datatracker wrote:

> different content.

I think this is similar to multipart/mixed.

>  Or we may have a set of related representations that
> resource, or related content?).

My understanding is that they are related contents.

>  And there is yet a third option -- one

Hmm, I missed that. I think this is similar to multipart/alternative and I agree with you that this is separate semantics. If my understanding is correct, then I agree that this needs to be fixed. So either the 3rd choice should be out-of-scope or the document should define 2 media types for different semantics.

> each other 

I think the first 2 are compatible.

>-- are we not defining three different semantical

Best Regards,
Alexey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 May 2019 15:11:25 +0200

Hi Alexey,

> 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.

> 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).

> Hmm, I missed that. I think this is similar to multipart/alternative

That wasn’t the intention.
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.

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.

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 4 May 2019 18:21:53 -0500

> 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).

> 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.  Thi…

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.

> 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 m…

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