Subject: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 2 Jan 2014 06:06:36 +0000

Hello all,

I have uploaded the following draft:
https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/

The draft introduces a notation to express CBOR data structures.

CBOR has recently been defined in RFC 7049. It is a general binary data format, which can be used to encode data in a structural way. Next to general data fields such as "integer" and "string", CBOR also supports signalling of e.g. arrays and maps.

RFC 7049 does not define how to write down CBOR data structures in specifications. I think it would be useful to have a standardised way for this, hence this new draft.

Since there is no working group chartered to do CBOR work, I have uploaded it as input to the general Applications Area working group.

I look forward to discussions on this, both technical and procedural. :-)

I wish you all a happy 2014!

Best regards,
Bert

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jan 2014 13:29:42 -0500

On Thu, Jan 2, 2014 at 1:06 AM, Bert Greevenbosch <
[email-masked]> wrote:

> CBOR has recently been defined in RFC 7049. It is a general binary data
> format, which can be used to encode data in a structural way. Next to
> general data fields such as "integer" and "string", CBOR also supports
> signalling of e.g. arrays and maps.
>
>
>
This is what I was worried about when CBOR was first proposed.

The networking world is currently moving to JSON as the interchange
standard. I totally oppose any alternative suggestion or proposal unless
there is an overwhelming need and there is no way to address that need
within the JSON framework.

The only way in which JSON currently falls short of my personal needs is
that it does not support efficient binary or text encodings. Which is why I
propose adding these features to the JSON encoding set which is what I do
in JSON-B. But what I do not do is to change the data model. It is possible
to express every JSON-B data stream in JSON and vice versa. The only area
that is not fully constrained is that since JSON does not have a native
binary type there is an assumption that BASE64 will be used (which is
obviously sub optimal for an encoding that can support UNICODE text strings
but there you have it.

Further, I don't accept the notion that there has to be a new schema for
each encoding format. Having a schema to document protocols is very useful.
My PROTOGEN tool generates the code and the specification from the same
source. But even though PROTOGEN was designed to generate programs that
generate protocols that use JSON format, it can be used to generate a
protocol that uses XML or ASN.1. In fact one of the predecessors of the
tool was used to write SAML/1.0.

It is not possible to use my tool to implement an ASN.1 or XML based
specification using their own schema languages as they are baroque with too
many unnecessary and brain damaged features. Nor is it possible to specify
the tight control on element ordering etc that XML schema provides because
in my experience those features are utterly useless.

I would like to get to a position where we can use a single data model to
represent the protocol flows at all layers in the stack above the IP layer.
There are good reasons for not wanting to use a text based encoding for
every purpose and for wanting to have the option of using compression. But
these can be added within the JSON data model just as there are different
encodings supported in the ASN.1 and XML frameworks.

-- 
Website: http://hallambaker.com/

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 6 Jan 2014 01:20:43 +0000

Hi Phillip,

Thank you for your feedback. Please find my answers inline, indicated with [BG].

Best regards,
Bert

From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: 03 January 2014 02:30
To: Bert Greevenbosch
Cc: [email-masked]
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."

On Thu, Jan 2, 2014 at 1:06 AM, Bert Greevenbosch <[email-masked]> wrote:
Hello all,

 

The networking world is currently moving to JSON as the interchange standard. I totally oppose any alternative suggestion or proposal unless there is an overwhelming need and there is no way to address that need within the JSON framework.

The only way in which JSON currently falls short of my personal needs is that it does not support efficient binary or text encodings. Which is why I propose adding these features to the JSON encoding set which is what I do in JSON-B. But what I do not do is to change the data model. It is possible to express every JSON-B data stream in JSON and vice versa. The only area that is not fully constrained is that since JSON does not have a native binary type there is an assumption that BASE64 will be used (which is obviously sub optimal for an encoding that can support UNICODE text strings but there you have it.

[BG] I think there is a straight-forward mapping from JSON to CBOR. This is a strength of CBOR, as - quite similar to your proposed JSON-B - it can be used to encode JSON data without loss of information or structure.
 
Further, I don't accept the notion that there has to be a new schema for each encoding format. Having a schema to document protocols is very useful. My PROTOGEN tool generates the code and the specification from the same source. But even though PROTOGEN was designed to generate programs that generate protocols that use JSON format, it can be used to generate a protocol that uses XML or ASN.1. In fact one of the predecessors of the tool was used to write SAML/1.0.

[BG] One of the main goals indeed is documenting protocols, i.e. writing down data structures in standards. But CDDL is designed to be processed by machines too - with low complexity.

It is not possible to use my tool to implement an ASN.1 or XML based specification using their own schema languages as they are baroque with too many unnecessary and brain damaged features. Nor is it possible to specify the tight control on element ordering etc that XML schema provides because in my experience those features are utterly useless.

[BG] Yes, definitely we do not want a complex schema language such as that of XML. This is why I would like to try to keep CDDL as concise and simple as possible. Each feature needs to have careful consideration on whether its complexity is justifiable.

I would like to get to a position where we can use a single data model to represent the protocol flows at all layers in the stack above the IP layer. There are good reasons for not wanting to use a text based encoding for every purpose and for wanting to have the option of using compression. But these can be added within the JSON data model just as there are different encodings supported in the ASN.1 and XML frameworks.

[BG] Yes, binary encoding is good. CBOR certainly can be used to compress JSON.

[BG] Thanks again for your comments!
-- 
Website: http://hallambaker.com/