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

[Nico Williams <[e-mail]>]

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.

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).

> 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).

>> - 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?

Nico
--