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

[Henk Birkholz <[e-mail]>]

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