Re: [Json] Canonicalization

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 21 February 2013 00:33 UTC

Return-Path: <James.H.Manger@team.telstra.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 E44D021E8049 for <json@ietfa.amsl.com>; Wed, 20 Feb 2013 16:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58o0lgRrOk4l for <json@ietfa.amsl.com>; Wed, 20 Feb 2013 16:33:57 -0800 (PST)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DA44321E803C for <json@ietf.org>; Wed, 20 Feb 2013 16:33:56 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,705,1355058000"; d="scan'208";a="120641622"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 11:33:54 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6992"; a="113932353"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 21 Feb 2013 11:33:54 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 21 Feb 2013 11:33:53 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Francis Galiegue <fgaliegue@gmail.com>
Date: Thu, 21 Feb 2013 11:33:52 +1100
Thread-Topic: [Json] Canonicalization
Thread-Index: Ac4Pwng4eU3Qn8VSTGCiahP302TwsAAACLwA
Message-ID: <255B9BB34FB7D647A506DC292726F6E11507634EE0@WSMSG3153V.srv.dir.telstra.com>
References: <BF7E36B9C495A6468E8EC573603ED9411513E818@xmb-aln-x11.cisco.com> <A723FC6ECC552A4D8C8249D9E07425A70F897263@xmb-rcd-x10.cisco.com> <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11507634C37@WSMSG3153V.srv.dir.telstra.com> <CALcybBA5ED=qj-=DXMuH_2A=d3VpkRV6KM8vtu62shRxvhm+hA@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11507634CD2@WSMSG3153V.srv.dir.telstra.com> <CALcybBBUowq6sO=vumbDutbYsKw_k8MUvYRtWJqEBfAzyNWzVg@mail.gmail.com>
In-Reply-To: <CALcybBBUowq6sO=vumbDutbYsKw_k8MUvYRtWJqEBfAzyNWzVg@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "draft-staykov-hu-json-canonical-form@tools.ietf.org" <draft-staykov-hu-json-canonical-form@tools.ietf.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Canonicalization
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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, 21 Feb 2013 00:33:58 -0000

Francis,
Your number is greater than 1e21 so the c14n format would be:
2.090989012323981098230918232983908091823098098019283019823098e+26

If you are exchanging data with an implementation that rounds numbers to fit in 64-bit floats then you obviously will not agree on the exact value. I don't think that is really a c14n issue, however.

Perhaps an IETF JSON c14n spec would need to repeat the JSON.stringify rules as opposed to just referencing them. My point is that JSON.stringify picks a really useful form for numbers (and strings), it is a canonical form (exactly 1 form for any number or string), it is already precisely specified, there are multiple production implementations. That is a great basis for a highly-interoperable IETF JSON c14n spec.

--
James Manger


> -----Original Message-----
> From: Francis Galiegue [mailto:fgaliegue@gmail.com]
> Sent: Thursday, 21 February 2013 10:32 AM
> To: Manger, James H
> Cc: json@ietf.org; draft-staykov-hu-json-canonical-form@tools.ietf.org
> Subject: Re: [Json] Canonicalization
> 
> On Thu, Feb 21, 2013 at 12:20 AM, Manger, James H
> <James.H.Manger@team.telstra.com> wrote:
> [...]
> >
> > Done (almost).
> >
> > The JSON.stringify format for numbers is NOT limited to 64-bit
> floats. It effectively says format the number without an exponent if it
> is in the range [1e-6, 1e21); otherwise format it with 1 digit before
> the decimal point. There is no limit to the number of digits, ie the
> precision.
> >
> 
> Well, I can tell you that it _is_ limited...
> 
> Go to the site in my signature, try this:
> 
> {
>     "maximum":
> 209098901232398109823091823.2983908091823098098019283019823098,
>     "exclusiveMaximum": true
> }
> 
> as a schema, and as data, input:
> 
> 209098901232398109823091823.29839080918230980980192830198230981
> 
> As I use a language which has the capability to deal with such numbers,
> this answers false -- but I use JSON.stringify() to format the results
> of validation: look at how the numbers are formatted.
> 
> --
> Francis Galiegue, fgaliegue@gmail.com
> Try out your JSON Schemas: http://json-schema-validator.herokuapp.com