Re: [Json] [Technical Errata Reported] RFC7493 (5354)

[Anders Rundgren <[e-mail]>]

Since we presumably agree on that integers represented as JSON Numbers can (in a scheme constrained by IEEE-754 double precision), cover exactly the range -(2**53) to 2**53, the issue boils down to the ability validating that you actually are sending or receiving integers within that range.

Validation is (at least on paper), only a problem on the ECMAScript side and essentially only concerns the values -9007199254740993 and 9007199254740993.

In practice however, the problem is *way* bigger since almost no other JSON tools bother about integer limits at all; 64-bit integers are pretty much the de-facto standard.

Feel free rejecting this errata report.  Personally, I stick to "int53".

Anders


On 2018-05-11 07:01, Anders Rundgren wrote:
> Right, if you violate the 2**53 limit all bets are off.  I don't find that particularly surprising.
> 
> Using Chrome:
>   > var t = 9007199254740993
>   > console.log(t)
>     9007199254740992
> 
> In a Java-based tool of mine:
> setInt53(long value) {
>       if (value < MAX_INT || value > MAX_INT) {
>           throw new IOException("Value out of range:" + value);
>       }
> 
> Anders
> 
> 
> On 2018-05-10 21:49, Joe Hildebrand wrote:
>> I disagree with this pretty thoroughly.  Here is some example NodeJS code to illustrate why:
>>
>> ```js
>> const START = Number.MAX_SAFE_INTEGER - 2
>>
>> const buf = Buffer.alloc(8)
>> for (let i = 0; i < 5; i++) {
>>     const x = START + i
>>     buf.writeDoubleBE(x)
>>     const y = buf.readDoubleBE()
>>     console.log(`${x} 0x${buf.toString('hex')} ${y} ${x === y}`)
>> }
>> ```
>>
>> And its output:
>>
>> 9007199254740989 0x433ffffffffffffd 9007199254740989 true
>> 9007199254740990 0x433ffffffffffffe 9007199254740990 true
>> 9007199254740991 0x433fffffffffffff 9007199254740991 true
>> 9007199254740992 0x4340000000000000 9007199254740992 true
>> 9007199254740992 0x4340000000000000 9007199254740992 true
>>
>> The point is that Number.MAX_SAFE_INTEGER is that last “integer" that has an unambiguous bit pattern, such that it round trips without the possibility of something else having been intended.
>>
>>
>>> On May 9, 2018, at 11:02 PM, RFC Errata System <[e-mail]> wrote:
>>>
>>> The following errata report has been submitted for RFC7493,
>>> "The I-JSON Message Format".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata/eid5354
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Anders Rundgren <[e-mail]>
>>>
>>> Section: 2.2
>>>
>>> Original Text
>>> -------------
>>> An I-JSON sender cannot expect a receiver to treat an integer whose
>>> absolute value is greater than 9007199254740991 (i.e., that is
>>> outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
>>>
>>> Corrected Text
>>> --------------
>>> An I-JSON sender cannot expect a receiver to treat an integer whose
>>> absolute value is greater than 9007199254740992 (i.e., that is
>>> outside the range [-(2**53), (2**53)]) as an exact value.
>>>
>>> Notes
>>> -----
>>> The limit is presumably derived from ECMAScript which says:
>>>
>>> "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value"
>>>
>>> However, Number.MAX_SAFE_INTEGER is 9007199254740991.
>>>
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> RFC7493 (draft-ietf-json-i-json-06)
>>> --------------------------------------
>>> Title               : The I-JSON Message Format
>>> Publication Date    : March 2015
>>> Author(s)           : T. Bray, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : JavaScript Object Notation
>>> Area                : Applications
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>>
>>> _______________________________________________
>>> json mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/json
>>
>