Re: [Json] Limitations on number size?

Nico Williams <> Thu, 11 July 2013 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7CA821F9F8E for <>; Thu, 11 Jul 2013 14:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id re29SEJFxedt for <>; Thu, 11 Jul 2013 14:57:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF68321F9F80 for <>; Thu, 11 Jul 2013 14:57:09 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 850291005D for <>; Thu, 11 Jul 2013 14:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=7dJIji186OtfRhOHKR9i 1pIfGgE=; b=kUlQFwb1w9xgxr9vZPTN+72bMqt5Xd2dIqmIC7eNcevyJL/O/0jv NMGYrUhdtkkrI2jWkQFURs686tHouPSchsE6bIJ0NXWPI0BbXK75doP4yaNs2HWR n63r4ss0XGQXV57KLR8ZFMyxGK5ObwBKCiD1IHxIhTd3hW79h6XLyvg=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 256F210058 for <>; Thu, 11 Jul 2013 14:57:08 -0700 (PDT)
Received: by with SMTP id e11so7608390wgh.30 for <>; Thu, 11 Jul 2013 14:57:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GRwGsDh8GceTL2gRqcB631YyuOzJr5NBZBgP3ANGwK8=; b=c+EnyCaSRxOVhai4KISf9VefGWfWAXvmc71L6M9Xmj+omW6RENiBZzmjqnr8BLpZ07 rpl4fR9j8nrXcEVrPhTQmn4wIwmyQtxtOEGVW8y7g7glao98rI6SPbAyrzdyAokWR3xU MrfC0EkNYiFRT/7qEusCQ3xLpz4zSQkc8jldWluSL7yr3pO8h2jkShJRgBn7GMxVo7M8 0DGYTmBKtbrAinpxM/OwYO8SWBL4A8jurt0tDC/EIUWJraml4xiPvCqLvbb6fi8CvXVS +TJoX1iCLkTbiOxYf9XjX4YRH+UqF7DYzHFTsQPQjjcs9nSbum4m3aSINqgwa0R4BWzf h9rw==
MIME-Version: 1.0
X-Received: by with SMTP id z1mr22830333wje.14.1373579827490; Thu, 11 Jul 2013 14:57:07 -0700 (PDT)
Received: by with HTTP; Thu, 11 Jul 2013 14:57:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 11 Jul 2013 16:57:07 -0500
Message-ID: <>
From: Nico Williams <>
To: Francis Galiegue <>
Content-Type: text/plain; charset=UTF-8
Cc:, Bjoern Hoehrmann <>, "Peter F. Patel-Schneider" <>, Jorge Chamorro <>
Subject: Re: [Json] Limitations on number size?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jul 2013 21:57:15 -0000

On Thu, Jul 11, 2013 at 4:28 PM, Francis Galiegue <> wrote:
> On Thu, Jul 11, 2013 at 11:03 PM, Nico Williams <> wrote:
> [...]
>> That's not responsive to Peter's comment.  Just as we shouldn't leave
>> out bignums, we cannot require bignum support either, and people who
>> create open APIs with the intention to interop will have to face this
>> (and related) problems.
> I do not deny this. However:

Great!  :)

>>> The number production grammar is perfect as it is, I see no reason to change it.
>> The *grammar* is, the semantics are underspecified.
> I don't believe the JSON RFC should _require_ any semantics. Advice,
> yes, why not. But API programmers are well aware that they have to
> deal with their own language's/other people's languages limitations.
> So, even then it does not look necessary at all.

Well, OK, but whether we're dealing with APIs or protocols (or plain
document formats), we need to concern ourselves with compatibility
(APIs) and interoperability (protocols).  This requires more than
grammar.  If we specify no semantics then we're stuck with either the
maximal interpretation of the grammar (binary strings! bignums! allow
dup names! [since no specific handling of dup names can be considered
a maximal interpretation...]) or an agreed subset, de facto or de

Given that we're here, that we have formed a WG tasked with looking
into this, I think it's proper to look at the question of semantics.
You don't want to -- fair and noted, but we have a charter that had
consensus, and we may have consensus to actually do something in this
space, with or without you.  At some point the chairs will have to
take action and make some consensus calls (I know, they have, but
their earlier consensus calls were not, i think, phrased usefully _in
retrospect_; they may yet take another swing and succeed).

My proposed consensus calls:

1a) Minimal edit noting divergent interpretations -- yes or no?

1b) If not, should we conclude without further ado, or consider (3)
below?  -- conclude or work on I-JSON?

2) If yes to (1a), note a likely-to-interop subset of JSON in the same
update -- yes or no?

3) Regardless of the answers to (1) and (2), should we re-charter to
include publishing of an Internet JSON as a work item -- yes or no?

That should suffice for now.  If we get consensus for (1a), (2),
and/or (3), we'll surely need more consensus calls later, but I think
the content of a minimal update and a likely-to-interop subset of JSON
are both possible to produce "mechanically", so to speak, leaving only
minor controversies plus any controversies in producing I-JSON.