Re: [Json] Limitations on number size?

Carsten Bormann <cabo@tzi.org> Wed, 05 June 2013 15:52 UTC

Return-Path: <cabo@tzi.org>
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 251B621F9AAE for <json@ietfa.amsl.com>; Wed, 5 Jun 2013 08:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJUQ6JtsNnw8 for <json@ietfa.amsl.com>; Wed, 5 Jun 2013 08:51:52 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1383B21F9AB1 for <json@ietf.org>; Wed, 5 Jun 2013 08:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r55FpfkA004987; Wed, 5 Jun 2013 17:51:41 +0200 (CEST)
Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 032443788; Wed, 5 Jun 2013 17:51:40 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <C30B2D0D-75A7-49A5-A190-5AD5DC1FCDCC@vpnc.org>
Date: Wed, 5 Jun 2013 17:51:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B8F8F96-F7B6-4734-9553-087A993482A4@tzi.org>
References: <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com> <C42654A3-E218-45A8-B368-4A60CB89619D@vpnc.org> <C4D8E604-E4F8-408B-B7DD-97226300C212@tzi.org> <CAK3OfOjDp=S=HZ5LTP3L+rqq1VjhSShakmBOJD9aPiN8fSULKw@mail.gmail.com> <C30B2D0D-75A7-49A5-A190-5AD5DC1FCDCC@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1503)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Limitations on number size?
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 05 Jun 2013 15:52:02 -0000

On Jun 4, 2013, at 16:07, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> And this is the point where one of the chairs says "please suggest specific wording changes to RFC 4627".

I like Tim's idea of a separate "best practices" document and look
forward to the process of creating it (Popcorn!).  However, some
things need to be said in the specification.  Here's my take:

<NEW>
Relationship between JSON and JavaScript

As the name implies, JSON was defined using the literal notation the
JavaScript language uses for its data objects; some restrictions were
made to make it more robust to potential changes in the JavaScript
language.  With that derivation made, JSON is now a specification
separate from JavaScript.

Properties of JavaScript (and changes to the JavaScript specification
[ECMAscript]) do not automatically transfer to JSON.  For example,
considerations about the source character set for JavaScript programs
do not influence what is admissible in a JSON document.  Another
example is the number format: JSON can represent numbers in arbitrary
precision by just supplying the necessary number of decimal digits.
JavaScript uses a number model derived from IEEE 754 binary double
precision numbers; the precision and range it can represent natively
therefore is a subset of the precision and range possible in JSON.

This clear separation of the two specifications does not mean that
users of JSON can always ignore JavaScript properties: A sizable part
of the JSON ecosystem is either using JavaScript implementations or
implementations that have been optimized for interaction with
JavaScript implementations.  Depending on the area of application, a
JSON-based protocol may do well to consider JavaScript's specific
properties.  Discussion of best practices for JSON-based protocols is
outside the scope of this specification.  Here, we just want to point
out that, for example, exclusively using numbers natively
representable in JavaScript is not a requirement of the JSON format.

Grüße, Carsten