IETF Logo Mail Archive

Re: [Json] Limitations on number size?

R S <sayrer@gmail.com> Wed, 05 June 2013 05:23 UTC

Return-Path: <sayrer@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 EF69221F9A1B for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 22:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 vW26+nnOIDNE for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 22:23:14 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2B21F9A1A for <json@ietf.org>; Tue, 4 Jun 2013 22:23:13 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t59so910147wes.20 for <json@ietf.org>; Tue, 04 Jun 2013 22:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0hekzcIZFy2SmEa0hVKK8EpRoPH8i7557p1EhoqDyzg=; b=ipdXeqoKm1pDg9rd2jzrrM66c4LjdCsXyYVxGdu3A6L9gmf3g1bvAKA0wnmfTp2+2F RzAHNL7YmrmoKPQBBuj4RBr/Iz7U4yuhofjJM168sNNX40tAgevZDt5JJstwlPSUcEAE iy8hef5LSx7dLqwJ+TQRy2y5I0d5Hj1ac0sDtH3ezRudKrxARqvyGDJKf3vJliaQqWTu Kwqed2zCBYU8s4wySGs2V2GSHxEqsB+L7fWPT8NAZSmKkW5K0SmLpT8invbys2Z1qZ43 18IJvW/QYtj1Z5exa1RWTdxMybTHebG94z+zvBSDWUYftVg3RHOKqyN59CZV1WiVS/dZ 5ihA==
MIME-Version: 1.0
X-Received: by 10.181.13.42 with SMTP id ev10mr4740461wid.1.1370409793151; Tue, 04 Jun 2013 22:23:13 -0700 (PDT)
Received: by 10.194.83.35 with HTTP; Tue, 4 Jun 2013 22:23:13 -0700 (PDT)
In-Reply-To: <CAK3OfOgO_DgP=O-hpMRJNYicnWs9S00zY=B2xZ5tM6++RqXYig@mail.gmail.com>
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> <CAK3OfOi6uNcXLCcStg90j2LqqdyVWQeoBAd0Mad-EjFEDyixpw@mail.gmail.com> <51AE63B1.80800@crockford.com> <CAChr6Szu11Qtbc9JGrG-bNvq=SCN-f81dZ1GoH_sz+KvddE0nw@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411527BC7D@xmb-aln-x11.cisco.com> <CAChr6SxzAQ+MFG60foM915Za+nroo6yy=JL1N40dZsx84u6rMg@mail.gmail.com> <CAK3OfOgO_DgP=O-hpMRJNYicnWs9S00zY=B2xZ5tM6++RqXYig@mail.gmail.com>
Date: Tue, 04 Jun 2013 22:23:13 -0700
Message-ID: <CAChr6SzKnf9RH4LXjPm_wDhzZPiVrzesPpvSv_0XTMGC2nuZkw@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="f46d04388df1eaeb1504de61641f"
Cc: "json@ietf.org" <json@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, Douglas Crockford <douglas@crockford.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>
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 05:23:15 -0000

On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Tue, Jun 4, 2013 at 9:06 PM, R S <sayrer@gmail.com> wrote:
> > On the issue at hand, it might be good to rewrite the beginning of the
> > "Number" section along these lines:
> >
> > - The representation of numbers is similar to that used in most
> programming
> > languages.
> > + JSON numbers are arbitrary precision, and represented in a manner
> similar
> > to that used in most programming languages.
>
> It might be nice to be able to specify some ranges that MUST be
> supported by decoders, but in practice I think we can't (and probably
> shouldn't try to) even do that.
>


Agreed that we shouldn't try. That's one of the most toxic standards group
activities: Moving Blame Around.

The real problem is that number ranges differ between systems--something
that has nothing to do with JSON.

The ship has sailed. Besides, most JSON numbers fit in 32 bits, and most
JSON values are strings.

- Rob

v2.23.0 | Report a Bug | By Email