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

From: RFC Errata System <[email-masked]>
Date: Wed, 9 May 2018 22:02:06 -0700 (PDT)

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 <[email-masked]>

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

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 10 May 2018 13:49:48 -0600

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 <[email-masked]> wrote:
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 11 May 2018 07:01:22 +0200

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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 11 May 2018 10:21:37 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 May 2018 15:24:11 +0200

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

As I mentioned, you can’t validate that you are receiving -2**53, with a stock, fully interoperable I-JSON decoder implementation.

Both ECMAScript and I-JSON are right in taking out 2**53 out of the safe space.

(And, of course, lots more integers can be represented in binary64, e.g. all numbers 2**53+2*n where n is an unsigned integer < 2**52.  This is just not very useful for interoperable exchange of integers via JSON; neither for n=0 nor for other values of n.)

> Feel free rejecting this errata report.  

Yes, that is what should be done.

> Personally, I stick to “int53".

(int54, if such a thing existed, is still not I-JSON safe at MININT54 = -2**53.)

Grüße, Carsten

---

From: "Matthew A. Miller" <[email-masked]>
Date: Fri, 11 May 2018 12:38:49 -0600

RFC Editor and AD, please reject errata 5354 of RFC 7493.

Thank you to all in evaluating.

- m&m

Matthew A. Miller