Re: [Cbor] CBOR-then-data example in EDHOC (was: draft-ietf-cbor-file-magic-07.txt)

Carsten Bormann <> Thu, 16 December 2021 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB51C3A08B2 for <>; Thu, 16 Dec 2021 02:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5IGcKP-0XxLA for <>; Thu, 16 Dec 2021 02:33:13 -0800 (PST)
Received: from ( [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDAA73A08AE for <>; Thu, 16 Dec 2021 02:33:11 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4JF7jp6nGjzDClZ; Thu, 16 Dec 2021 11:33:02 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 16 Dec 2021 11:33:02 +0100
X-Mao-Original-Outgoing-Id: 661343582.330338-364027e2c54cd99d0862a648319b7143
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Christian Amsüss <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] CBOR-then-data example in EDHOC (was: draft-ietf-cbor-file-magic-07.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Dec 2021 10:33:18 -0000

On 2021-12-16, at 09:35, Christian Amsüss <> wrote:
> Signed PGP part
> Hello Carsten,
> in yesterday's discussion of this it was briefly mentioned that we
> don't have a good example of CBOR-then-data yet.
> There is in the EDHOC draft:
> (The data format stays unnamed, but it is a preexisting example).

Right.  Let me cite:

>> These identifiers are encoded in CBOR and thus self-delimiting. They are sent in front of the actual EDHOC message, and only the part of the body following the identifier is used for EDHOC processing.¶
>> Consequently, the application/edhoc media type does not apply to these messages; their media type is unnamed.

We never documented CBOR header + non-CBOR data in the same way that we documented CBOR sequences (RFC 8742) because there is no general way to do a media type for them — we never considered doing a structured syntax suffix for them, for example.

This doesn’t mean CBOR header + non-CBOR data is in some way a second-class citizen; we probably should go ahead and document this case (e.g., in an informational document) so people remember to put elements of support into their CBOR generic decoders.

We also may want to think about a variant of .cbor that bundles the specification of a CBOR header with the specification of what is essentially a byte string (which may be described in some form that we can describe a byte string in CDDL, e.g., by giving its length, or its structure via .abnfb).

Grüße, Carsten