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

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor