Subject: Re: [Anima-signaling] Discuss: Using CBOR for anima signaling

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 25 May 2015 21:20:47 +0000

(re-sending, now that I'm subscribed to the list)

Sorry, finally started paying attention to this thread.  I'll top post some general remarks, then see if there's anything else in the thread that needs attention.

A profile of CBOR (removing all of the bits you don't need, like floats, chunked encoding, and most of the tags) is a good fit for places where you want fast processing of structured data with generic code.  

At the app layer, with web APIs, we have found that JSON-shaped data is good at modeling lots of different data, good at being bound into various programming languages, does NOT require schema to syntax-parse, and is adequate at extensibility.  This combination is a good fit for lots of problems.  When combined with a fast binary encoding such as CBOR, without JSON's warts (search RFC 7159 for the word "interoperable" to find some of them) and the ability to handle binary data gracefully, a different set of problems are a good fit.

As to whether Wireshark can parse CBOR, here is a proof point:

https://github.com/iptube/SPUDshark

If I was any kind of lua programmer, there would be a generic CBOR implementation for lua that this plugin would call.  However, you can see that I got the basics done in a relatively small amount of inexpert code.  I would welcome pull requests to tighten it up.  Probably, I would prefer to just display the diagnostic format specified in 7049.

As to whether a profile of CBOR is a good fit for the routing layer, I don't think I can say without gathering data.  I'm working on getting a FPGA implementation of CBOR done so we can look at performance versus a less-structured format.  There are a couple of known security edge cases that would need to be called out and defended against (such as a string of 0x818181... that might blow out a careless implementation's stack).  My intuition is that by the time you created a custom TLV that did everything you wanted and was small enough to be interesting, you would have created a less-optimal CBOR that everyone would have to implement from scratch.

> Yes, if you had to brain disassemble a CBOR hexdump there would 
> be a few more bits to understand than with TLV, but you'd really 
> never shuold have to do this.

Not that many more bits.  On days when I've been hacking CBOR, I can parse it by sight.  Agree that you should never have to do it, though, because it's not as much fun as solving the real problem at hand.

> JSON would be the target diagnostic format.

Well, the augmented diagnostic notation in Section 6 of RFC 7049 (http://tools.ietf.org/html/rfc7049#section-6) is likely exactly what you want.

> Give us a rough draft of how they would look in JSON.

If anyone who knows GDNP wants to sit down with me and bang out some JSON and CBOR representations, I'd be happy to help.

> Is there some information about the runtime footprint of JSON and CBOR?

Carsten's CBOR parser in C is about 880 bytes of ARM code when compiled with -Os.  More is needed for the DOM-like code, if you want that.  JSON code is actually a bit larger, usually, because of the need to deal with string escaping, etc.  However, here is a really small version that is not known to be widely-used or portable: 

https://github.com/quartzjer/js0n/blob/master/src/js0n.c

> Now I'm confused. If it isn't JSON, what am I representing 
> in a CBOR-encoded message?

CBOR is a different syntax than JSON, that is effectively a superset (as long as you didn't want integers > 64bits, which don't interop in JSON anyway).  What you're encoding in CBOR is a data model that you decide on at protocol design time, with a defined extensibility model.

-- 
Joe Hildebrand