Re: [Json] Limitations on number size?

R S <sayrer@gmail.com> Thu, 11 July 2013 05:42 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 61BE521F9D5A for <json@ietfa.amsl.com>; Wed, 10 Jul 2013 22:42:45 -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 vV6FkHnKMqAU for <json@ietfa.amsl.com>; Wed, 10 Jul 2013 22:42:44 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DF05D21F9D3B for <json@ietf.org>; Wed, 10 Jul 2013 22:42:43 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id k10so12181836wiv.7 for <json@ietf.org>; Wed, 10 Jul 2013 22:42:42 -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=xq49+6H8xQQZb4VzQjET7ygBFlqmzo8vNgzqiQ05488=; b=c+kv8QmTfYPtCZjh0DEbhK2piYc//yjVBtqulqrvy3mUKw9ohEv4ya9fQ8fXv3oCL9 47ipWOGldg/HpTRxnDjqhKRDe0okAzZXJvVlbMXf0tD+Zl81hOp1X1IgY0QZ7jJHPrGg Qns755mk0AJLtQ9C7+o223J6edbwPPDKDMFOLWMQV+feS15GZVSHWp1mDswETXa4GSVZ rFuOSzMCpulxwdlSioo+IUzgzM0EL5oH95Co9lAsjO9iw3wFwbGJ4jYJCCowdJRUUBJe wfyP0XCTzQp5e2e1gisjgFNBAIFmu8ooISYq/nUDpWr0QfwibTgzinbetvS4o863Ev/b 4yOg==
MIME-Version: 1.0
X-Received: by 10.194.63.229 with SMTP id j5mr19511526wjs.79.1373521362742; Wed, 10 Jul 2013 22:42:42 -0700 (PDT)
Received: by 10.194.44.138 with HTTP; Wed, 10 Jul 2013 22:42:42 -0700 (PDT)
In-Reply-To: <CAGrxA26fskGojrw1dbpFFRcpkedQkWMYiAMON2nnY8H2XLbzXg@mail.gmail.com>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51DC7F87.6060503@gmail.com> <CAGrxA24v5L7oCGxEOwecJSLCNiLrSWSt=jFJMA0M9E8fztNLag@mail.gmail.com> <20130710024215.GO9153@mercury.ccil.org> <CAO1wJ5RRk+GoJKUizp1Q92rRMNy62sYER-=6SUwjPh30DSuBwg@mail.gmail.com> <CAGrxA26fskGojrw1dbpFFRcpkedQkWMYiAMON2nnY8H2XLbzXg@mail.gmail.com>
Date: Wed, 10 Jul 2013 22:42:42 -0700
Message-ID: <CAChr6Sw-W5BYEmb=uRQSa6EpsfFzk3ug5b47PavPVy77HHp0nQ@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Tatu Saloranta <tsaloranta@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97518eaf26a04e135dccc
Cc: John Cowan <cowan@mercury.ccil.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "json@ietf.org" <json@ietf.org>, Jacob Davies <jacob@well.com>, Nico Williams <nico@cryptonector.com>, "Peter F. Patel-Schneider" <pfpschneider@gmail.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: Thu, 11 Jul 2013 05:42:45 -0000

Is this thread making any progress over the minimal edit I proposed? I
think not, fwiw.

- Rob


On Wed, Jul 10, 2013 at 9:10 PM, Tatu Saloranta <tsaloranta@gmail.com>wrote;wrote:

>
>
>
> On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies <jacob@well.com> wrote:
>
>> On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <cowan@mercury.ccil.org>
>> wrote:
>> > Apparently, there are already practical problems with interchanging
>> > 64-bit longs: google for [json large numbers bugs] for lots of reports.
>>
>> The canonical one was Twitter IDs, where they had to introduce a
>> (string) field in their JSON APIs called "id_str" which is not
>> guaranteed to be equal to the obsolete-but-included (number) field
>> "id".
>>
>> > While there are apparently int32-only systems out there, it's clearly
>> > understood that they are unusually restricted: such is not the case
>> > for JavaScript-hosted implementations.
>>
>> Yes, this is why I think the specification itself should note that for
>> interoperability with Javascript, the Javascript size limitations must
>> be respected, even if the specification does not require that in
>> itself. The number of JSON-to-Javascript implementations or uses must
>> surely outnumber all other uses of JSON by several orders of magnitude
>> so I'd argue that as far as "running code" goes the limitation on
>>
>
> Any data to back that up? I would not assume this -- JSON is being used a
> lot for service-to-service integration, as well as by native mobile clients.
> Javascript as client is certainly important, but I would not assume any
> particular majority (even simple one), and certainly not an order of
> magnitude.
>
> My experience wrt problem reports differs from that of John's, in that
> while feature requests have been filed to allow limitation or truncation,
> these have not been highly voted or actively followed. User community also
> has not brought this up as a significant issue either.
> I suspect this is because it is relatively easy to work around the problem
> if and when it occurs. Developers are surprisingly resourceful in solving
> problems.
>
> practical, interoperable number size is quite real and surprising to
>> people trying to send data to Javascript from non-JS environments
>> where larger numbers are available. (I went so far in the Java
>> libraries I wrote as to encode/decode longs & Big* as strings.)
>>
>
> Mentioning limitations is reasonable, and Javascript can be used as a
> common example. There is nothing wrong in outlining challenges, best
> practices. But I don't like fearmongering.
>
> Javascript's limited support for numbers is not a JSON-specific problem --
> same goes for all data formats as well; for example, XML. This is why some
> concerns wrt JSON seem overblown to me.
>
> -+ Tatu +-
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>