Subject: [Cbor] What's your opinion of using CDDL to simultaneously define CBOR and JSON?

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Sep 2021 10:45:19 -0700

Right now, the EAT draft is using CDDL to simultaneously define the EAT protocol such that it can be encoded in either CBOR or JSON. This also gives transcoding of the protocol between CBOR and JSON which is useful at the Verifier. There is also some interest in expanding to ASN.1. That seems doable. Then maybe on to YANG, but that seems harder.

The goal here is NOT to be able to translate any arbitrary CBOR to/from any arbitrary JSON. It is just for the protocol messages defined by EAT.

Mostly this has been straight forward in EAT: base64 encoding of binary data and a few other little items. See here <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3>. That CBOR has tags and JSON doesn’t is the biggest mismatch and has to be compensated for in other ways.

I personally think this is working pretty well and is a good idea. The main text for each claim is described only in CDDL. A few little general rules, like b64 of binary data, say how to handle the encoding for JSON.

This kind of all started when CWT was created out of JWT, but that was all before CDDL. If we set out to define JWT plus CWT today from scratch, would we use CDDL?

Other comments?

Thx,

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 7 Sep 2021 22:16:44 +0200

Hi Laurence,

> If we set out to define JWT plus CWT today from scratch, would we use CDDL?

that reads a bit like a loaded question. While CDDL can do what is 
intended to do (e.g., 
https://datatracker.ietf.org/doc/html/rfc8428#section-11), I am not sure 
what that has to do with defining "JWT plus CWT today from scratch". 
Could you elaborate on your motivation a little bit (excluding the can 
of worms that is the association with YANG modeled data and ASN.1 
modeled data very deliberately for now).

Viele Grüße,

Henk

On 07.09.21 19:45, Laurence Lundblade wrote:
> Right now, the EAT draft is using CDDL to simultaneously define the EAT 
> protocol such that it can be encoded in either CBOR or JSON. This also 
> gives transcoding of the protocol between CBOR and JSON which is useful 
> at the Verifier. There is also some interest in expanding to ASN.1. That 
> seems doable. Then maybe on to YANG, but that seems harder.
> 
> The goal here is NOT to be able to translate any arbitrary CBOR to/from 
> any arbitrary JSON. It is just for the protocol messages defined by EAT.
> 
> Mostly this has been straight forward in EAT: base64 encoding of binary 
> data and a few other little items. See here 
> <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3>. 
> That CBOR has tags and JSON doesn’t is the biggest mismatch and has to 
> be compensated for in other ways.
> 
> I personally think this is working pretty well and is a good idea. The 
> main text for each claim is described only in CDDL. A few little general 
> rules, like b64 of binary data, say how to handle the encoding for JSON.
> 
> This kind of all started when CWT was created out of JWT, but that was 
> all before CDDL. If we set out to define JWT plus CWT today from 
> scratch, would we use CDDL?
> 
> Other comments?
> 
> Thx,
> 
> LL
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 14:48:01 -0400

Laurence Lundblade <[email-masked]> wrote:
    > at the Verifier. There is also some interest in expanding to
    > ASN.1. That seems doable. Then maybe on to YANG, but that seems harder.

Sorry to nit-pick, but expanding to *DER* (or BER) would be easy.

Rewriting the CDDL in ASN.1 serves no purpose in my opinion.
It would be an entirely new spec.

Similiarly, rewriting to YANG is meaningless.
YANG serializes to CBOR, JSON, XML and other stuff.
Serializing the CDDL to XML might be interesting to someone.
(not met)

    > scratch, would we use CDDL?

JWT/CWT would have been described in CDDL.
And we can describe it today in CDDL.
I imagine that if we do new iterations of documents may include CDDL for
this.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Sep 2021 12:05:33 -0700

Hi Henk,

I don’t mean this to be a loaded question. I really do want to hear what people have to say about this even if it is negative. 

As far as I know, no I-D or standard has defined a protocol solely, directly, and abstractly in CDDL such that it simultaneously specifies CBOR, JSON and other encoding except EAT.

Thanks for the SenML reference. It mostly answers my question. It is a standards track document that specifies a protocol that is to be encoded in CBOR, JSON, XML and EXI. That means a lot of people think it is a good idea to define protocols with multiple encodings and it went through a last call and IESG review.

However, it doesn’t entirely answer the question, because the primary definition of SenML is in prose, not in CDDL. For EAT, the primary definition of the protocol is in CDDL. There is no prose that says what the CDDL says in many cases. 

Note also that while the CDDL RFC does mention use with JSON (https://datatracker.ietf.org/doc/html/rfc8610#appendix-E), it doesn’t quite say that it is for the simultaneous definition of CBOR and JSON.

I’ll ask my CWT/JWT question another way.  What if we had some brand new protocol to define and wanted it to encode in CBOR and JSON, would we use CDDL as the primary expression of it?

Another way to ask this is to ask why SenML didn’t use CDDL as the primary representation. What is some limits in CDDL? Was it easier to do in prose? Lack of a convention to go from CDDl to XML? Didn’t think of it at the time?

The other answer I’m getting is here is the lack of anyone saying “Laurence, you dummy, didn’t you know about the xxx problem with doing that?” :-)

LL

> On Sep 7, 2021, at 1:16 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> that reads a bit like a loaded question. While CDDL can do what is intended to do (e.g., https://datatracker.ietf.org/doc/html/rfc8428#section-11), I am not sure what that has to do with defining "JWT plus CWT today from scratch". Could you elaborate on your motivation a little bit (excluding the can of worms that is the association with YANG modeled data and ASN.1 modeled data very deliberately for now).
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Sep 2021 21:14:37 +0200

On 2021-09-08, at 20:48, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

Less is more.
I don’t know why people think that having the same data in five different representations aids interoperability.

> Sorry to nit-pick, but expanding to *DER* (or BER) would be easy.

There is a lot of weirdness in that representation format (ASN.1 tags, SEQUENCE vs. SET, etc.) that will create noise in a language like CDDL.

> It would be an entirely new spec.

At least one could cover the BER/DER idiosyncrasies that way.
But what is the point?

> Serializing the CDDL to XML might be interesting to someone.

You forgot to throw EXI into the mix.

> And we can describe it today in CDDL.

And that’s what we should do.
(For CWT — somebody else can do that for JWT.)

> I imagine that if we do new iterations of documents may include CDDL for

Yep.  I plan to do that in the next couple of days.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 17:07:18 -0400

Laurence Lundblade <[email-masked]> wrote:
    > As far as I know, no I-D or standard has defined a protocol solely,
    > directly, and abstractly in CDDL such that it simultaneously specifies
    > CBOR, JSON and other encoding except EAT.

RFC8995 uses CDDL to describe a JSON encoding of enrollment status, and
voucher status POST content.

draft-ietf-anima-constrained-voucher uses the same CDDL with a CBOR encoding.

Is that what you are looking for?

    > I’ll ask my CWT/JWT question another way.  What if we had some brand
    > new protocol to define and wanted it to encode in CBOR and JSON, would
    > we use CDDL as the primary expression of it?

Yes.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Sep 2021 15:00:32 -0700

> On Sep 8, 2021, at 2:07 PM, Michael Richardson <[email-masked]> wrote:
> 

In concept yes, but in practice not what I was thinking/expecting. As far as I can see draft-ietf-anima-constrained-voucher does not make direct normative reference to voucherstatus-post or voucherstatus.cddl.

I didn’t try to read these documents so hopefully I haven’t missed something. I did some greps to look for the references I was expecting. Is there some way that draft-ietf-anima-constrained-voucher is directly referencing the CDDL (e.g. voucherstatus-post) that I’ve missed. It looks like a parallel/equivalen definition to me.

LL

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 21:27:40 -0400

Laurence Lundblade <[email-masked]> wrote:
    >>> directly, and abstractly in CDDL such that it simultaneously
    >>> specifies CBOR, JSON and other encoding except EAT.
    >>
    >> RFC8995 uses CDDL to describe a JSON encoding of enrollment status,
    >> and voucher status POST content.
    >>

    > In concept yes, but in practice not what I was thinking/expecting. As
    > far as I can see draft-ietf-anima-constrained-voucher does not make
    > direct normative reference to voucherstatus-post or voucherstatus.cddl.

Appendix B provides examples.
   Appendix B.  Constrained BRSKI-EST messages . . . . . . . . . . .  37
     B.1.  enrollstatus  . . . . . . . . . . . . . . . . . . . . . .  37
     B.2.  voucher_status  . . . . . . . . . . . . . . . . . . . . .  38

Section 5.1 refers to them via /vs and /es resources:

The Content-Format 50 ("application/json") MAY be supported and
Content-Format 60 ("application/cbor") MUST be supported by the Registrar for
the /vs and /es resources.
Content-Format TBD3 MUST be supported by the Registrar for the /rv resource.
If the "ct" attribute is not indicated for the /rv resource in the link
format description, this implies that at least TBD3 is supported.

    > I didn’t try to read these documents so hopefully I haven’t missed
    > something. I did some greps to look for the references I was
    > expecting. Is there some way that draft-ietf-anima-constrained-voucher
    > is directly referencing the CDDL (e.g. voucherstatus-post) that I’ve
    > missed. It looks like a parallel/equivalen definition to me.

It doesn't reference the CDDL at all.
Why would it?  We don't need to change it.
We simply say that having that content in CBOR format is a MUST.

Perhaps the document is deficient and should say things more explicitely.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Sep 2021 11:07:17 +0200

Hi Laurence,
adding more rats due to UCCS scope,

both the web tokens, senml and actually cose (but Jim was in high 
frequency interaction with us) predate RFC 8610. That might be one 
reason for the surprising volume of English text.

Actually, I am really in favor of replacing 'prose' with CDDL. That is 
exactly the point. It reads faster, is precise, has low noise, and 
provides a quick comprehensive overview of message or document layouts. 
Essentially, it's like this typical "figure in section 2.5" where you 
finally have this aha! moment with the benefit that it is the actual 
specification and not just an overview.

In consequence, I think that creating a CDDL definition for CWT is a 
useful and practical contribution to the "CCS" part in UCCS. Carsten 
took the liberty to run a quick review cycle with a proposal and the 
result of a late night's work can be found here:

> https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/pull/7

Please mind, that I still think that this is additional content that 
extends the contribution of this I-D. Ripple effects definitely should 
effect abstract & intro content.

Additionally, I am still quite opposed to address CDDL for 
https://datatracker.ietf.org/doc/html/rfc7519#section-6 in the UCCS I-D. 
That has nothing to do with CWT or UCCS. Maybe some JOSE folks can offer 
more insight.

I read the term polluting somewhere in the discussion, I think. I am 
against polluting the content of the UCCS I-D with a related but 
different problem statement. We can (and probably should) do that, but 
not there.

Viele Grüße,

Henk

On 08.09.21 21:05, Laurence Lundblade wrote:
> Hi Henk,
> 
> I don’t mean this to be a loaded question. I really do want to hear what 
> people have to say about this even if it is negative.
> 
> directly, and abstractly in CDDL such that it /simultaneously/ specifies 
> Thanks for the SenML reference. It mostly answers my question. It is a 
> standards track document that specifies a protocol that is to be encoded 
> in CBOR, JSON, XML and EXI. That means a lot of people think it is a 
> good idea to define protocols with multiple encodings and it went 
> through a last call and IESG review.
> 
> However, it doesn’t entirely answer the question, because the primary 
> definition of SenML is in prose, not in CDDL. For EAT, the primary 
> definition of the protocol is in CDDL. There is no prose that says what 
> the CDDL says in many cases.
> 
> Note also that while the CDDL RFC does mention use with JSON 
> (https://datatracker.ietf.org/doc/html/rfc8610#appendix-E 
> <https://datatracker.ietf.org/doc/html/rfc8610#appendix-E>), it doesn’t 
> quite say that it is for the simultaneous definition of CBOR and JSON.
> 
> I’ll ask my CWT/JWT question another way.  What if we had some brand new 
> protocol to define and wanted it to encode in CBOR and JSON, would we 
> use CDDL as the primary expression of it?
> 
> Another way to ask this is to ask why SenML didn’t use CDDL as the 
> primary representation. What is some limits in CDDL? Was it easier to do 
> in prose? Lack of a convention to go from CDDl to XML? Didn’t think of 
> it at the time?
> 
> The other answer I’m getting is here is the lack of anyone saying 
> “Laurence, you dummy, didn’t you know about the xxx problem with doing 
> that?” :-)
> 
> LL
> 
> 
> 
>> On Sep 7, 2021, at 1:16 PM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Laurence,
>>
>> https://datatracker.ietf.org/doc/html/rfc8428#section-11 
>> <https://datatracker.ietf.org/doc/html/rfc8428#section-11>), I am not 
>> sure what that has to do with defining "JWT plus CWT today from 
>> scratch". Could you elaborate on your motivation a little bit 
>> (excluding the can of worms that is the association with YANG modeled 
>> data and ASN.1 modeled data very deliberately for now).
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>> Right now, the EAT draft is using CDDL to simultaneously define the 
>>> EAT protocol such that it can be encoded in either CBOR or JSON. This 
>>> also gives transcoding of the protocol between CBOR and JSON which is 
>>> useful at the Verifier. There is also some interest in expanding to 
>>> The goal here is NOT to be able to translate any arbitrary CBOR 
>>> to/from any arbitrary JSON. It is just for the protocol messages 
>>> defined by EAT.
>>> Mostly this has been straight forward in EAT: base64 encoding of 
>>> binary data and a few other little items. See here 
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3 <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3>>. 
>>> That CBOR has tags and JSON doesn’t is the biggest mismatch and has 
>>> to be compensated for in other ways.
>>> I personally think this is working pretty well and is a good idea. 
>>> The main text for each claim is described only in CDDL. A few little 
>>> general rules, like b64 of binary data, say how to handle the 
>>> encoding for JSON.
>>> This kind of all started when CWT was created out of JWT, but that 
>>> was all before CDDL. If we set out to define JWT plus CWT today from 
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Sep 2021 13:51:10 +0200

OK, I haven’t really answered the original question, and that is a good question.

Before I do, let me reiterate that it is not valuable per se to make a specific application available in all random data formats that come to mind.  Less is more.

But there may be a good reason to span multiple representation formats. SenML is probably the most pertinent example here, as practical use of the format already spans more than a decade, at the start of which XML and even EXI were more popular than today, and it makes a lot of sense to provide smooth backwards and forwards compatibility paths for a format like this that is intended to span rather different (in function and in vintage) processing and storing applications.

CDDL covers JSON and CBOR in RFC 8428; Relax-NG is used for XML in Section 7 of RFC 8428, and the EXI representation variant is also described in W3C XML Schema (WXS) in Section 8 of RFC 8428 (as the efficient use of EXI forces the use of WXS).

> As far as I know, no I-D or standard has defined a protocol solely, directly, and abstractly in CDDL such that it simultaneously specifies CBOR, JSON and other encoding except EAT.

Well, if you strike “and other encoding”, SenML does use CDDL simultaneously for CBOR and JSON.  It does have to provide variant parts in that CDDL spec as the data definition in JSON needs to live with the more limited expressibility in JSON.  More generally, any data definition that wants to use more of the CBOR generic data model than JSON supports will need some extra CDDL to handle that.

draft-ietf-cbor-cddl-control, in Section 4 (Features) has an example that discusses simultaneous specification of JSON and CBOR in passing.
But I don’t think we have common idioms or best practices here yet; SenML and the example in cddl-control are the published examples today.

> However, it [SenML] doesn’t entirely answer the question, because the primary definition of SenML is in prose, not in CDDL.

CDDL can only provide the data structure definition.
Semantics still needs to be in prose, so I don’t know how “solely” can be achieved.

But, yes, it is nice to see how much of the content of RFC 7071 collapses into a half-page of CDDL :-)
(Prose is still needed for the semantics.)

> For EAT, the primary definition of the protocol is in CDDL. There is no prose that says what the CDDL says in many cases. 

That is great (“the grace of being born late” in German politics).

> Note also that while the CDDL RFC does mention use with JSON (https://datatracker.ietf.org/doc/html/rfc8610#appendix-E), it doesn’t quite say that it is for the simultaneous definition of CBOR and…

No it doesn’t say that explicitly, probably because the target audience of that appendix is people who just want to get their JSON-based protocol done, for which CDDL is quite useful.
But RFC 8610 also points to RFC 8428 as an example for CDDL data definitions.

> I’ll ask my CWT/JWT question another way.  What if we had some brand new protocol to define and wanted it to encode in CBOR and JSON, would we use CDDL as the primary expression of it?

Absolutely.
When developing the brand new protocol, after finding a reason to actually support both representation formats, we probably would place more attention on making the two variants of the format similar enough that a single piece of CDDL can define both.
To me, JWT and CWT are different enough that I don’t see a big reason to squeeze both into a single piece of CDDL.

> Another way to ask this is to ask why SenML didn’t use CDDL as the primary representation. What is some limits in CDDL?

See above.

> Was it easier to do in prose?

See above.

> Lack of a convention to go from CDDl to XML?

Definitely.  
Actually, XML came first for SenML (note the ML at the end, which was artfully replaced by “measurement list” during its eight-year gestation :-).

> Didn’t think of it at the time?

Obviously we did think about it: 
We do have a common data definition for CBOR and JSON.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Sep 2021 10:21:28 -0700

> On Sep 8, 2021, at 12:14 PM, Carsten Bormann <[email-masked]> wrote:
>> 

Very much agree that less is more. I think two are generally enough and sometimes necessary:

— JSON because it is ubiquitous
— CBOR because JSON is not compact

There may be some protocols where only one or the other is enough, but I think both may actually be necessary for some protocols. People thought it was necessary for CWT and JWT. I think it is necessary for EAT for example. EAT would be of far less value if it only supported one or the other.

It would be nice to have general, well-understood conventions for using CDDL to define protocols that encode in both JSON and CBOR.

We should generally resist encodings like DER and XML, but they are not out of the question for specific use cases.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Sep 2021 10:44:07 -0700

> On Sep 8, 2021, at 6:27 PM, Michael Richardson <[email-masked]> wrote:
> 
> Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:

I was expecting it to say that something like “the voucher status message here is defined by CDDL in section 5.7 of RFC 8995 called voucherstatus, but must be encoded in CBOR rather than JSON”. Perhaps this reference is indirect through the message type or other.

> Perhaps the document is deficient and should say things more explicitely.

I’m not making any comment on draft-ietf-anima-constrained-voucher here. I’m just trying to understand if it is an example of what I am proposing.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 10 Sep 2021 12:02:40 -0700

Thomas helped get EAT on track so the makefile for the document validates the CDDL in the document against the diag format examples using the cddl tool. It even pulls CDDL files from the SUIT and CoSWID GitHub repository to do that. It’s pretty cool. I’d like to really make it fully work at scale if possible. Here are some thoughts (you probably have had too) that seemed worth writing down and related issues:

Use CDDL rather than prose when possible
The main structure for JSON and CBOR should be expressed in CDDL. Use prose to fill in what can’t be expressed in CDDL.

Understandably CDDL wasn’t the main expression for documents for documents in the past, but now that CDDL is well-established practice it can be the front-and-center main expression (maybe even for XML).

Explicitly author the CDDL to encode to both CBOR and JSON
We’re close on this with RFC 8610 Appendix E <https://datatracker.ietf.org/doc/html/rfc8610#appendix-E>, but there are a some intrusive issues:

One is labels/keys. JSON requires text string. CBOR encoding should really use integers for compactness. My PR for UCCS <https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/pull/6> accommodates this by having separate files for JSON and CBOR labels. I’m not sure I can use Carsten’s PR for UCCS <https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/pull/7> because the integer labels are bound in. I’m not set on the CDDL in UCCS covering JWT, but EAT does somehow require one CDDL expression of a claims-set that is common to CBOR and JSON.

Binary data. This is straight forward in prose, but I don’t think “cddl spec.cddl validate instance.json” knows what to do with this.

Tags. Since JSON doesn’t have tags, other JSON structure has to be used to accommodate.

Some sort of #ifdef or conditionally constructed CDDL for JSON/CBOR variance is the knee-jerk solution, but maybe there is a better solution.

Put CDDL in a .cddl file and use the make process to pull it into the text
Don’t put the CDDL in markdown / main text of the document. If it is in a separate file, it can be used in automated ways with the cddl tool.

Publish CDDL files for reference/inclusion
Drafts and RFCs should publish CDDL files so that they can be made use of by referring specifications. 

Github for publishing and curl to make a copy for local use?

One challenge here is that some referred-to CDDL may be CBOR-only. For example, EAT refers to SUIT and SUIT is CBOR-only. EAT explicitly addresses this in prose, but there’s no good CDDL constructs (yet) to support this, particularly to support verifying a JSON example.

Validate diag and JSON format examples against CDDL
The cddl tool is used to verify that any examples in the draft conform to the CDDL in the draft. This is a good check for both the CDDL and the example.

Support for diag-CBOR-CDDL validation seems pretty good. Less so for JSON.

In EAT, trying to support this combo of CBOR and JSON seems a bit like going down a garden path. I’ve encountered some wilderness, but haven’t fallen off a cliff, so it seems worthwhile.

The most important thing for me here is figuring out the what and where for a claims-set in CDDl that works for simultaneously for JWT and CWT. I just don’t see how EAT can be expressed in CDDL without that.

LL

> On Sep 9, 2021, at 4:51 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 20 Sep 2021 09:47:17 -0700

Hi folks,

EAT allows one token to be put in another — nested tokens — even a CWT in a JWT in a UCCS… I think there are use cases for this in complicated devices made of multiple subcomponents (e.g., a car) and daisy-chained Verifiers.

I think this is a level of using CDDL=>CBOR/JSON that is beyond SenML and things I’ve seen so far.

Some of this is in the current EAT draft, but it needs work. I am also attempting to have have the cddl tool validate the CDDL and examples as part of the document build process. My plan is to publish a new EAT draft in the next few weeks that describes all this better.

The draft will include CDDL for a claims-set that is common to CWT, JWT and UCCS. That is the CDDL that describes CWT, JWT and UCCS.

We can discuss from there.

LL

> On Sep 10, 2021, at 12:02 PM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Sep 9, 2021, at 4:51 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Note also that while the CDDL RFC does mention use with JSON (https://datatracker.ietf.org/doc/html/rfc8610#appendix-E <https://datatracker.ietf.org/doc/html/rfc8610#appendix-E>), it doesn’t quite say that it is for the simultaneous definition of CBOR and JSON.
>>