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

Thomas Fossati <> Tue, 19 February 2019 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD1C6130DE3; Tue, 19 Feb 2019 01:58:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lfADD4M8JIib; Tue, 19 Feb 2019 01:58:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B667D130E94; Tue, 19 Feb 2019 01:58:04 -0800 (PST)
Received: by with SMTP id h6so4808797itl.1; Tue, 19 Feb 2019 01:58:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C0yW2EVf5eB2m/jx3pBGOWCdp3xGjR9wbcAHh13LiME=; b=ZfVXMHjNSD5rMwROd4ZMOnOH6siA2LeVUlpurM9SM7fbLWPuPNHCUIbocIVnLXwWh7 TaeBvgJLwgw3ec+zNPN/Gukb+rbK6JWt3rmN36lirEg/G0w6Csovjf5UfZ0R7o4JguY/ IQdI48CtTVUmdQgZFPUlZGRY0eIsVmC3fXy6+MWbzY9zyCYAaEvKs6jap8x+ThKwEY5l xF1EtIY0jG31C1q3kN1fkURaTvsZdXSfOc2Dxvo547CnMKZyOvWiuPgOotcI1AZkZ2IZ aZlYlDmDYqFvE0P3gvix1o1Tw6b2zb5yZ+jQAXfu68ax518N/vSLYUuAaDwlV9kYQnYn jfOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C0yW2EVf5eB2m/jx3pBGOWCdp3xGjR9wbcAHh13LiME=; b=VuLlEERTv9Nnf5vJEjgGTesfJxFOno8FAQEVEC257fUXwZb4KNlx1pkgzKs7MWzJT1 7gnBqc5C6imtExH1KSCi4PrfCBWr8928VBkCq8AXj2oja9VYbMSTNKrqz5K5Q6KLOJKt XO+oVyyQPC9d5UQofdkxt760XOQrM6geWEMmEqlb+jUespJcUrr7gQEbDtHgqetFsw8k YTC1lwIrFZBUznE3fvkBJ1i33TSvZQXcd/nNjXyCACYgSXa6qixIPfgEMhcQzjRn3VR9 thzxUE+9dFNa7uI3sYYvNKTGIXBZDkKwWPCRAbuX78MapyljCVF3pbEVNK3iTceh2Pfg G5DA==
X-Gm-Message-State: AHQUAuYtbKCOqy03g0mvFia5+slMy21tKeaTEjwthCIf7DvZZcvGgZjn CK8luIUZ4X2oVN1ir0Q6Onaka8uf5VsGqNTGKFQ3lnUL
X-Google-Smtp-Source: AHgI3IbKQYUXZD5tBh9+UeWAqNfsTXBee007BSF18bhczeE/lx8bRbO06C7/o9SX/7/oNcdyooH8xeP7tEBVVE7fc1Q=
X-Received: by 2002:a02:3b51:: with SMTP id i17mr10106280jaf.68.1550570283639; Tue, 19 Feb 2019 01:58:03 -0800 (PST)
MIME-Version: 1.0
References: <000901d4c2f8$4b69a640$e23cf2c0$> <> <00f901d4c624$f313cb30$d93b6190$>
In-Reply-To: <00f901d4c624$f313cb30$d93b6190$>
From: Thomas Fossati <>
Date: Tue, 19 Feb 2019 09:57:52 +0000
Message-ID: <>
To: Jim Schaad <>
Cc: Klaus Hartke <>,,
Content-Type: multipart/alternative; boundary="000000000000f4a7a605823c46a0"
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: Tue, 19 Feb 2019 09:58:08 -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
(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;
- multiparts of kind (B) MUST not include other multiparts of the same

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.


On Sat, Feb 16, 2019 at 6:25 PM Jim Schaad <> 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.
> 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
> > -----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
> > 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
> > representations."
> >
> > > Also I note that this draft is currently expired and needs to be
> >
> > Yes. Soon™.
> >
> > Klaus
> >
> > [1]
> >
> > I
> > [2]
> _______________________________________________
> core mailing list