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

[Carsten Bormann <[e-mail]>]

On May 23, 2013, at 17:35, Nico Williams <[e-mail]> wrote:

> On Thu, May 23, 2013 at 2:15 AM, Carsten Bormann <[e-mail]> wrote:
>> On May 23, 2013, at 07:27, Nico Williams <[e-mail]> wrote:
>> 
>>> - 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
>> 
>> This is about like saying there should only ever be 64-bit integers (or 128-bit, while we are at it).
> 
> ECMAScript specifically only allows that.  That's where the
> restriction comes from.

JSON ≠ JavaScript.  
JavaScript's numbers are IEEE 754 double precision.
That is not at all a property of JSON.  
(It *is* something you care about if one or two of the peers speaking JSON actually are written in JavaScript and you are using JavaScript primitives to operate on the JSON.)

> Many a ECMAScript and/or JSON implementation use NaN coding, which is
> probably why this restriction is there in the first place (though
> that's just a guess; I'm sure there's a list archive somewhere with a
> lengthy discussion I could check; I don't care).

Now you lost me -- JSON doesn't have NaNs.
(Another thing that CBOR has that you can't use in a JSON subset.)

>> The serializer can choose one of multiple representations (or, if it is expedient, it can stick with one).
>> Like with different size of integers, there is little effort in a deserializer to support different sizes of floats.
> 
> I wouldn't insist on having a canonical representation.  I would
> prefer to have a canonical representation if possible.  The biggest
> issue would be the need to sort object keys, which I'd not insist on
> (but it's nice to have the option to, and many a JSON encoder provides
> this).

I think Paul is working on c14n for CBOR.
As I said, I don't want to go there...
(If you think you need c14n, you probably have a bug in your architecture.)

>>> - might as well have a type for "octet string" -- no base64 encoding please
>> 
>> Yes, we are just not using the liturgical name "octet string" :-)
> 
> Yes it's there and I missed it?

Yes, we call them "byte strings" (major type 2).
(They are actually the main reason I started work on CBOR.)

Grüße, Carsten