Re: [Json] Limitations on number size?

Tim Bray <tbray@textuality.com> Wed, 05 June 2013 02:48 UTC

Return-Path: <tbray@textuality.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 3646521F9B10 for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 19:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.643
X-Spam-Level:
X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 fHRg5bNFCJHL for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 19:48:02 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5521F9B15 for <json@ietf.org>; Tue, 4 Jun 2013 19:48:01 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id b10so840412vea.2 for <json@ietf.org>; Tue, 04 Jun 2013 19:48:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=338AgPIHR2unA3vOlOVn1OIFRT/ddkSnOBbOG75ghTM=; b=PT5jGjUczRuziiEWu9SZyKYA0w77ihv30HpwJPUvHodJ/mHzCkPcAc/3Fz+y9WnhZp vvNKqLCn8eTMmLr9XJOe7imtQVr4zA/aBiYWifvnfaNRMHotvI1j03XFMbB0c11SPrPY gMs3NcyxQkf0Ns5Ltad/GEhsKH8sNIelCB7SbadJ/m3MeftyPs0OtU8h9xTqTn65XwHz DZ5UGuaDOUWtiYTuM1qYuTExlcbrWjuQQ9i3/bVTDhd/MWcRAFeLpNyFuJGYK71XZzXN l4gYYlwibqa1jYYsQuwY+08un8J4mhH544OtKd+6M2CK41QH2N0BsiAv/3kvW46c8J5c q4Vw==
MIME-Version: 1.0
X-Received: by 10.58.6.141 with SMTP id b13mr19933050vea.45.1370400480964; Tue, 04 Jun 2013 19:48:00 -0700 (PDT)
Received: by 10.220.48.14 with HTTP; Tue, 4 Jun 2013 19:48:00 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAChr6SxzAQ+MFG60foM915Za+nroo6yy=JL1N40dZsx84u6rMg@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>
Date: Tue, 4 Jun 2013 19:48:00 -0700
Message-ID: <CAHBU6ivv_3S1Zb+CWpDGORA3THXmp+ChoG6HcdqjUbVseyjFPg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: R S <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b672c48de4ab304de5f3906
X-Gm-Message-State: ALoCoQkbczG7Bf1gXoV67wuY8EgNDZjUSzhaBCpjDCJef8v+ylScjKe8x3/Dh2e9TnUtlmgikDMD
Cc: Nico Williams <nico@cryptonector.com>, "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 02:48:06 -0000

Yeah, the number specification is a little flabby and omits the fact that
the base is 10
<old>
   The representation of numbers is similar to that used in most
   programming languages.  A number contains an integer component that
   may be prefixed with an optional minus sign, which may be followed by
   a fraction part and/or an exponent part.

   Octal and hex forms are not allowed.  Leading zeros are not allowed.

   A fraction part is a decimal point followed by one or more digits.

   An exponent part begins with the letter E in upper or lowercase,
   which may be followed by a plus or minus sign.  The E and optional
   sign are followed by one or more digits.
</old>

<proposal>
A number is represented in base 10 with no leading zeroes or punctuation
such as  commas or spaces.  It may have a preceding minus sign.  It may
have a "."-prefixed fractional part. It may have an exponent, prefixed by
"e" or "E" and optionally "+" or "-".
</proposal>



On Tue, Jun 4, 2013 at 7:06 PM, R S <sayrer@gmail.com> wrote:

> On Tue, Jun 4, 2013 at 6:46 PM, Matt Miller (mamille2) <mamille2@cisco.com
> > wrote:
>
>>
>> On Jun 4, 2013, at 7:40 PM, R S <sayrer@gmail.com>
>>  wrote:
>>
>> > On Tue, Jun 4, 2013 at 3:01 PM, Douglas Crockford <
>> douglas@crockford.com>wroteote:
>> >
>> >>
>> >> Keep in mind that this format has been working successfully in the wild
>> >> for over a decade. The goal here should be to do the least that is
>> >> necessary to formally upgrade its status from Informational, not to
>> attempt
>> >> to fix something that is already working well enough. It is only
>> because it
>> >> has been working well enough that we are considering the upgrade.
>> >
>> >
>> >
>> > Strongly agree. We should only be changing things that are incorrect or
>> > obsolete. You can't write an interoperable JSON implementation by
>> reading
>> > RFC 4627 at the moment, but number precision is not one of the
>> > deal-breakers.
>> >
>>
>> Would you be willing to contribute specific wording proposals to address
>> those deal-breakers?
>>
>
>
> Sure. I wrote a reasonably good JSON implementation after RFC 4627 but
> before ES5, and then had to update it to work on the Internet after ES5. We
> also have code at my current employer that will break if certain numbers
> are not transmitted as strings. It's workable, although inconvenient.
>
> That said, I am also pretty sure that Douglas knows which changes from ES5
> need to go in. The main concerns for me are changes to the grammar that
> allow more than just objects and arrays as the root value, and the
> allowance in RFC 4627 for syntactic extensions (that is not realistic given
> ES5 rules).
>
> 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.
>
> The current RFC is a little under-specified.
>
> - Rob
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>