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

Jim Schaad <> Sat, 16 February 2019 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 039EF130D7A; Sat, 16 Feb 2019 10:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OT8VVYTj9g40; Sat, 16 Feb 2019 10:25:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3B9B126C7E; Sat, 16 Feb 2019 10:25:15 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 Feb 2019 10:25:08 -0800
From: Jim Schaad <>
To: 'Klaus Hartke' <>
CC: <>, <>
References: <000901d4c2f8$4b69a640$e23cf2c0$> <>
In-Reply-To: <>
Date: Sat, 16 Feb 2019 10:25:06 -0800
Message-ID: <00f901d4c624$f313cb30$d93b6190$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHZeLzgd60hRSXGqZKN3jc6SJcBfgFxWGrPpc3KhGA=
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [core] draft-ietf-core-multipart-ct
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Feb 2019 18:25:18 -0000

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.


> -----Original Message-----
> From: Klaus Hartke <>
> Sent: Tuesday, February 12, 2019 9:50 AM
> To: Jim Schaad <>
> Cc:; WG <>
> Subject: Re: [core] draft-ietf-core-multipart-ct
> For context: [1] [2]
> Jim Schaad wrote:
> > 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]
> I
> [2]