Subject: [core] draft-ietf-core-multipart-ct

From: Jim Schaad <[email-masked]>
Date: Tue, 12 Feb 2019 09:27:54 -0800

An interesting question has come up with respect to this content type in the
ACE Working group.

Is there a way to indicate the different content types that one can deal
with inside of this content type.   One can have an ACCEPT option of types
A, B,  C and multipart.  However, there is no way to say which types one is
going to accept in the multipart.  The multipart could return content types
of D, E, F, and G.  However the combination of all 4 may not be what is
returned but instead a combination of two of them.  Thus the client could
understand D and E or D and F but not F and G.

If you say ACCEPT 62, do you accept any combination of nested content types?
Should something about this be placed into the draft?

Also I note that this draft is currently expired and needs to be reposted.

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 12 Feb 2019 18:50:10 +0100

For context: [1] [2]

> If you say ACCEPT 62, do you accept any combination of nested content types?

Yes. A CoAP request can include at most one Accept option and any
response must exactly that value as Content-Format or be an error
response. CoAP doesn't have a mechanism for negotiating the content
formats of representations embedded in other representations. I
stumbled upon the same problem with CoRAL.

> Should something about this be placed into the draft?

Yes. Proposed text: "CoAP doesn't have a mechanism for negotiating the
content formats of representations embedded in
application/multipart-core representations."

> Also I note that this draft is currently expired and needs to be reposted.

Yes. Soon™.

Klaus

[1] https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcmI
[2] https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk

---

From: Jim Schaad <[email-masked]>
Date: Wed, 13 Feb 2019 21:29:07 -0800

> -----Original Message-----
> From: Klaus Hartke <[email-masked]>
> Sent: Tuesday, February 12, 2019 9:50 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked] WG <[email-masked]>
> Subject: Re: [core] draft-ietf-core-multipart-ct
> 
> For context: [1] [2]
> 
> Jim Schaad wrote:
> Yes. A CoAP request can include at most one Accept option and any response
> must exactly that value as Content-Format or be an error response. CoAP
> doesn't have a mechanism for negotiating the content formats of
> representations embedded in other representations. I stumbled upon the
> same problem with CoRAL.
> 
> content formats of representations embedded in application/multipart-core
> representations."

Potentially add

"This is generally not an issue as an application is going to return either a fixed set of embedded content types.
Applications which have a need to return different sets of content formats embedded in an application/multipart-core content can negotiate this as a query parameter."

I am not sure that this is the correct wording, but I think providing guidance on a way to handle this problem is reasonable.

Jim
 
> [1]
> https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcm
> I

---

From: Jim Schaad <[email-masked]>
Date: Sat, 16 Feb 2019 10:25:06 -0800

Looking at this, it does seem to be a strange way to deal with things.  Of course the problem is made even more of a pain if you think about the possibility of having nested multipart contents.

While the following does may not be the greatest solution, I think that it might be a better answer:

1.  Define a new target attribute:  "mt-subtypes" which contains the list of any content type which can be returned in a multipart content.  This could be at the top level or anyplace in a tree.

2.  Define a new option: "mt-accept" which contains the list of sub-content types that the client can deal with.  This option would be defined as advisory on the part of the server, that is it can return content types which are not in the list, but where options exist in the possible returned content tree the requested types, in order, SHOULD be the ones chosen by the server.   I would propose the option be "Non-Critical, Safe, CacheKey, Repeatable".

I am not sure if I believe that the new option is part of the cache key or not.  I can see arguments on both sides, but I think I come down to yes.

Carsten,   I think that this issue (but maybe not this solution) needs to be put onto the agenda for the interim meeting next Wed.

Jim

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 19 Feb 2019 09:57:52 +0000

It has surfaced in the mailing list as well as in private exchanges that
there are two ways of looking at multipart-ct:
(A) as a mechanism to wrap multiple related things in a rigidly structured
way;
(B) as a mechanism to aggregate related thingsin flexible ways (e.g., the
EST-coaps credentials).

One approach to content negotiation for multiparts of kind (A) is to assign
the aggregate a separate type altogether (overriding C-F 62 with something
allocated on purpose from the FCFS portion of the codepoint space).  This
fits Accept’s semantics well.

Content negotiation with multiparts of kind (B) needs something like Jim’s
proposal.  The slight complication that potentially breaks Jim’s approach
is recursion.

To support this, I think the draft could say:
- multiparts of kind (A) SHOULD override the multipart C-F with their own;
and
- multiparts of kind (B) MUST not include other multiparts of the same
“kind”.

The above would make a recursive multipart (i.e., a 62 embedded in another
62) illegal and give Jim’s new content negotiation a well-defined semantics.

Cheers

On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad <[email-masked]> wrote:
>
> Looking at this, it does seem to be a strange way to deal with things.
Of course the problem is made even more of a pain if you think about the
possibility of having nested multipart contents.
> 1.  Define a new target attribute:  "mt-subtypes" which contains the list
of any content type which can be returned in a multipart content.  This
could be at the top level or anyplace in a tree.
>
> 2.  Define a new option: "mt-accept" which contains the list of
sub-content types that the client can deal with.  This option would be
defined as advisory on the part of the server, that is it can return
content types which are not in the list, but where options exist in the
possible returned content tree the requested types, in order, SHOULD be the
ones chosen by the server.   I would propose the option be "Non-Critical,
Safe, CacheKey, Repeatable".
>
> I am not sure if I believe that the new option is part of the cache key
or not.  I can see arguments on both sides, but I think I come down to yes.
>
> Carsten,   I think that this issue (but maybe not this solution) needs to
be put onto the agenda for the interim meeting next Wed.
> > Yes. A CoAP request can include at most one Accept option and any
response
> > content formats of representations embedded in
application/multipart-core
> > [2]
https://mailarchive.ietf.org/arch/msg/ace/vj5CYF8eRrra5yph2Z9ui3Gkllk
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Thomas

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Feb 2019 21:48:16 -0800

I did think about some of this when I put up the proposal.

For case (A), unless it is going to have options while doing a rigidly structured response, there is no need to have a value different than Accept 62.  In fact if there is really only one structured response, then there is not a need to have any accept option in the request at all.

For case (B), I thought about the recursive case and that is why I put the SHOULD and talked about options between multiple things while building the response.  I don’t think that there are going to be enough cases of a tree structure being returned that anything needs to be said about it one way or the other.  If that type of detail is really needed then I would expect that a GET would be replaced by a POST with the details of the response needed in the content of the POST.

In the semantics, I wanted to provide a minimal amount of information.  Thus the language about using it to provide guidance for specific pairs of content types that can go into a specific location.  The other place that I was thinking it might be useful would be in the case of a PUB-SUB server returning multiple content types where the set of equivalents might be restricted to the requested values rather than returning all possibilities.

Jim

From: Thomas Fossati <[email-masked]> 
Sent: Tuesday, February 19, 2019 1:58 AM
To: Jim Schaad <[email-masked]>
Cc: Klaus Hartke <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [core] draft-ietf-core-multipart-ct

It has surfaced in the mailing list as well as in private exchanges that there are two ways of looking at multipart-ct:
(A) as a mechanism to wrap multiple related things in a rigidly structured way;
(B) as a mechanism to aggregate related thingsin flexible ways (e.g., the EST-coaps credentials).

One approach to content negotiation for multiparts of kind (A) is to assign the aggregate a separate type altogether (overriding C-F 62 with something allocated on purpose from the FCFS portion of the codepoint space).  This fits Accept’s semantics well.

Content negotiation with multiparts of kind (B) needs something like Jim’s proposal.  The slight complication that potentially breaks Jim’s approach is recursion.

To support this, I think the draft could say:
- multiparts of kind (A) SHOULD override the multipart C-F with their own; and
- multiparts of kind (B) MUST not include other multiparts of the same “kind”.

The above would make a recursive multipart (i.e., a 62 embedded in another 62) illegal and give Jim’s new content negotiation a well-defined semantics.

Cheers

On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:
> > From: Klaus Hartke <[email-masked] <mailto:[email-masked]> >
> > To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
> > Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]>  WG <[email-masked] <mailto:[email-masked]> >
> [email-masked] <mailto:[email-masked]> 

-- 
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Feb 2019 08:03:32 +0100

> For case (A), unless it is going to have options while doing a rigidly structured response, there is no need to have a value different than Accept 62.  In fact if there is really only one structure…

Case (A) is somewhat hypothetical now, so let me give an example to find out whether that would be (A) or maybe even a new (C):

We do a FETCH with an array of selectors, which was defined as a content type of its own.  The return might be a specially defined content type for providing an array of responses, or it might simply be a multipart-core, laying out the selector results in the same sequence they were requested in the FETCH payload.  The specific semantics of the (sequence of objects in the) response body here come from the request body and its media-type!

(And the client might still use an Accept if there is another way to represent the array of results as well but the client specifically wants multipart-core.)

Grüße, Carsten