Re: [apps-discuss] Concise Binary Object Representation (CBOR)

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 23, 2013 at 1:27 AM, Nico Williams <[e-mail]>wrote:

> Thoughts:
>
>  - if we're going to have an RFC on JSON, might as well have one on
> some binary encoding of JSON
>
>  - yet another encoding.  yay.
>
>  - this encoding does suffice for encoding JSON
>
>  - this encoding can go beyond JSON -- this is good, but a strict
> JSON-equivalent subset should be specified
>
>  - yeah, multiple ways of encoding a given value suck; in particular,
> for the JSON-equivalent subset, there should be only doubles, no
> floats, no integers
>
>  - might as well have a type for "octet string" -- no base64 encoding
> please
>

+1 to Nico.

The only types I have found a need for in my JSON schema are:

Integer
Float
String (UTF8)
DateTime   (As RFC 3339 format string)
Binary (as base64 encoded string)
List (X)  - JSON List

I do think that it is worth calling out DateTime and Binary for special
treatment because they both appear very frequently in code. I have not
found a need for any other special format.


For Integers, I only use double for representation but that is a design
choice that does not affect bits on the wire. For a binary format I would
prefer that like JSON, the wire format be neutral with respect to the code
representation.

Since most of the proposals are of the form <type> <data> where <type> and
we only have 7 fundamental types it is quite easy to make the type octet
combine the type and length information. So if the integer fits in 2 bytes
then just use 2 bytes and mark the length in the type octet, the number 256
could be represented as:

X2 01 00

I would use twos compliment for all values and so a 64 bit unsigned integer
could potentially have 9 octets but that would be a rare event.

A side benefit to this approach is that big numbers are easily supported.


Representing floats is a lot harder than the specs I have written seem to
understand. In particular the main reason I would want a binary format for
JSON is that it is NOT possible to round trip floats from decimal format to
binary without special care.

So the main reason for using a binary JSON is going to be not introducing
the errors, possibly cumulative errors that round tripping from decimal to
binary introduces.

So we do need to have 32 bit and 64 it floats.


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