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

Anders Rundgren <anders.rundgren.net@gmail.com> Fri, 11 May 2018 08:21 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B497112E87B for <json@ietfa.amsl.com>; Fri, 11 May 2018 01:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzXTVLmZX321 for <json@ietfa.amsl.com>; Fri, 11 May 2018 01:21:43 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1317812E874 for <json@ietf.org>; Fri, 11 May 2018 01:21:43 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id l1-v6so1627671wmb.2 for <json@ietf.org>; Fri, 11 May 2018 01:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SmtiRwchdxIb1l4OBSwqJEEk33BIYlkBZwmLus48bLw=; b=ZAYaYdKib6L2gQmat8mgCQJBjyYxCRNZGmHagb8SfTkkzstCE/96Z3nslER/kQNpPY IsIihHeSpXZTcdUYY1vSFRmWLKN5rtGKWsnKnFL0azO7QFK5cOva1QSE/ar+MNStdxc6 1deEnpxSZemyn5KXe1KZKvwTy1UFZMSAemc6QSilXvXSMswL0vyerNqwjnelgBoMoZ3b RUXDLWwQbshn4/TCBrQ2krJzoVfFiNJtk0uVWUALPZXIEVrB3roXbXhdoZaToJZGXWNF KyWfsa+x6IKo2htKMIaVS5/JAqJmxSLVN8WHKmIRcSAV/oQSOBNGuevsStxKIcmJixH3 HHqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SmtiRwchdxIb1l4OBSwqJEEk33BIYlkBZwmLus48bLw=; b=af6UsDlysuFpWJLUk1cV+8Cuv8SZqFSC1hcNo8rAkyaddlSq2/UiRM+9/sbng6iMYr Ma6ThgjFm0BlX1+IoAKFMnzU2AHAX/twI8DxOMrw7kA8ZsrbnkQbswWL6aSBA6HuJDlN U3IJy+Qho/bTAiuipYaxTXl8efxBQkhB+U1nxcvrqeQhFH1RM7I0VGxRuGZUk3UPYR3p PE3mz5RvIuDLIVg2m717syH0I4kZvJsyS0aYjJAoX99ZQvnMZyhd7QF2E3ld/rhyOiif Clw0y/S5/yLPTKp8bvuyaEcDnQpc16fIjnBpPfZPQBe89IIzIb9gYS2NYx+OhCHIZl+T ZYzQ==
X-Gm-Message-State: ALKqPwcmcL2/egtDTM6eWTfbjrEPJTZtqZnhAt49qXOZdWXY6c+6f62S Van1inLwIjCrh8tLOJg1yNM0lg==
X-Google-Smtp-Source: AB8JxZqB6RKMN01KQwp4N636uFTYxLoNAyVi4shDfMtTbVRc3FDaDsf3zLuExdNSzFtQPitkXk2QDA==
X-Received: by 2002:a1c:c1c9:: with SMTP id r192-v6mr1195966wmf.120.1526026901158; Fri, 11 May 2018 01:21:41 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id m134-v6sm615634wmg.4.2018.05.11.01.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 01:21:40 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: Joe Hildebrand <hildjj@cursive.net>, json@ietf.org
References: <20180510050214.916C4B81EA7@rfc-editor.org> <4EB0B6DE-2416-4909-9EDA-975439055F33@cursive.net> <b23ce436-22c3-17bf-c830-59ee88b9fc2f@gmail.com>
Message-ID: <dea9478a-6752-b723-a303-ef3544c57f33@gmail.com>
Date: Fri, 11 May 2018 10:21:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <b23ce436-22c3-17bf-c830-59ee88b9fc2f@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/QufEMocViuAAmZAW5W-AhhDMSmw>
Subject: Re: [Json] [Technical Errata Reported] RFC7493 (5354)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 08:21:46 -0000

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 <rfc-editor@rfc-editor.org> 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 <anders.rundgren.net@gmail.com>
>>>
>>> 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
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>
>