Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string

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

On Fri, May 24, 2013 at 2:15 AM, Carsten Bormann <[e-mail]> wrote:

> On May 24, 2013, at 02:33, "Manger, James H" <
> [e-mail]> wrote:
>
> > A minor (non-controversial?) suggested change for draft-bormann-cbor:
> >
> > Section 4.1. "Converting From CBOR to JSON" 11th dot point says:
> >
> >  o  A bignum (major type 7, tag value 8 or 9) becomes a JSON number.
> >
> > This might be right in theory, but I don't think it is in practice.
> > Presumably a bignum was used because the value (or other expected value
> for the same field) is too large for normal (32-bit, 64-bit) number types,
> which are the types many implementations use represent a JSON number. Hence
> they will fail with a bignum.
>
> That is a very good point.
> I haven't done a survey of JSON implementations how they handle large
> numbers that look like integers.
> Of those for platforms that don't have bignums, I would expect many of
> them to create a double-precision float for large numbers.
> This doesn't fail, but loses precision.


Trying to do public key crypt afterwards is not going to work very well.

Other than Mathematica, I really cant think of any platform I would expect
to be able to start reading an integer and realize that it needs to be
treated as a bignum when it goes over 64 bits.

Like many parts of the JSON syntax that is something that the specification
demands but implementations are likely to vary on.


The idea that JSON can never change by an iota seems rather silly. The
specification is not really complete. Where difficult parts come up they
are ignored and so we don't know how implementations are expected to behave
for overflow or for NaN values.

Addressing such concerns is precisely what is expected when a spec enters
IETF process.


What are JSON parsers expected to do when they come across a token litteral
they don't understand?




> > I suggest converting a bignum to a base64url encoding (without padding)
> in a JSON string. This is what you get if the positive bignum tag was
> ignored and you just processed the byte string that followed. For a
> negative bignum stick "-" before the base64url encoding.
>
> That is certainly good advice if the bignum was, say, a value from an
> ECDSA signature, where losing precision destroys the utility.
> Less so if it was the US national debt (well, for a few more weeks, that
> will still fit in a 64-bit number :-).
>

If you then try to maintain the result by adding a hundred dollars every X
milliseconds then the count is never going to increase and you will #fail.

Hey, we have just found the way to fix the national debt...



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