I think you misunderstood the criticism. JSON does not have numeric precision limits. There are plenty of systems that use JSON that never involve JavaScript and which pack int64s.
On Sun, Mar 18, 2018, 1:55 PM Anders Rundgren <[email protected]> wrote: > On 2018-03-18 18:40, Mike Samuel wrote: > > A definition of canonical that is not tied to JavaScript's current range > of values would fit into more standards than the proposal as it stands. > Feel free submitting an Internet-Draft which addresses a more generic > Number handling. > My guess is that it would be rejected due to [quite valid] > interoperability concerns. > > It would probably fall in the same category as "Fixing JSON" which has not > happened either. > https://www.tbray.org/ongoing/When/201x/2016/08/20/Fixing-JSON > > Anders > > > > > On Sun, Mar 18, 2018, 12:15 PM Anders Rundgren < > [email protected] <mailto:[email protected]>> > wrote: > > > > On 2018-03-18 16:47, Mike Samuel wrote: > > > Interop with systems that use 64b ints is not a .001% issue. > > > > Certainly not but using "Number" for dealing with such data would > never be considered by for example the IETF. > > > > This discussion (at least from my point of view), is about creating > stuff that fits into standards. > > > > Anders > > > > > > > > On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren < > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto: > [email protected]>>> wrote: > > > > > > On 2018-03-18 15:47, Michał Wadas wrote: > > > > JSON supports arbitrary precision numbers that can't be > properly > > > > represented as 64 bit floats. This includes numbers like > eg. 1e9999 or 1/1e9999. > > > > > > rfc7159: > > > Since software that implements > > > IEEE 754-2008 binary64 (double precision) numbers > [IEEE754] is > > > generally available and widely used, good > interoperability can be > > > achieved by implementations that expect no more > precision or range > > > than these provide, in the sense that implementations > will > > > approximate JSON numbers within the expected precision > > > > > > If interoperability is not an issue you are free to do > whatever you feel useful. > > > Targeting a 0.001% customer base with standards, I gladly > leave to others to cater for. > > > > > > The de-facto standard featured in any number of applications, > is putting unusual/binary/whatever stuff in text strings. > > > > > > Anders > > > > > > > > > > > > > > > On Sun, 18 Mar 2018, 15:30 Anders Rundgren, < > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto: > [email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>>> > wrote: > > > > > > > > On 2018-03-18 15:08, Richard Gibson wrote: > > > >> On Sunday, March 18, 2018, Anders Rundgren < > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto: > [email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>>> > wrote: > > > >> > > > >> On 2018-03-16 20:24, Richard Gibson wrote: > > > >>> Though ECMAScript JSON.stringify may suffice for > certain Javascript-centric use cases or otherwise restricted subsets > thereof as addressed by JOSE, it is not suitable for producing > canonical/hashable/etc. JSON, which requires a fully general solution such > as [1]. Both its number serialization [2] and string serialization [3] > specify aspects that harm compatibility (the former having arbitrary > branches dependent upon the value of numbers, the latter being capable of > producing invalid UTF-8 octet sequences that represent unpaired surrogate > code points—unacceptable for exchange outside of a closed ecosystem [4]). > JSON is a general /language-agnostic/interchange format, and ECMAScript > JSON.stringify is *not*a JSON canonicalization solution. > > > >>> > > > >>> [1]: _ > http://gibson042.github.io/canonicaljson-spec/_ > > > >>> [2]: > http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type > > > >>> [3]: > http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring > > > >>> [4]: > https://tools.ietf.org/html/rfc8259#section-8.1 > > > >> > > > >> Richard, I may be wrong but AFAICT, our > respective canoncalization schemes are in fact principally IDENTICAL. > > > >> > > > >> > > > >> In that they have the same goal, yes. In that they > both achieve that goal, no. I'm not married to choices like exponential > notation and uppercase escapes, but a JSON canonicalization scheme MUST > cover all of JSON. > > > > > > > > Here it gets interesting... What in JSON cannot be > expressed through JS and JSON.stringify()? > > > > > > > >> That the number serialization provided by > JSON.stringify() is unacceptable, is not generally taken as a fact. I also > think it looks a bit weird, but that's just a matter of esthetics. > Compatibility is an entirely different issue. > > > >> > > > >> > > > >> I concede this point. The modified algorithm is > sufficient, but note that a canonicalization scheme will remain static even > if ECMAScript changes. > > > > > > > > Agreed. > > > > > > > >> > > > >> Sorting on Unicode Code Points is of course > "technically 100% right" but strictly put not necessary. > > > >> > > > >> > > > >> Certain scenarios call for different systems to > _independently_ generate equivalent data structures, and it is a necessary > property of canonical serialization that it yields identical results for > equivalent data structures. JSON does not specify significance of object > member ordering, so member ordering does not distinguish otherwise > equivalent objects, so canonicalization MUST specify member ordering that > is deterministic with respect to all valid data. > > > > > > > > Violently agree but do not understand (I guess I'm > just dumb...) why (for example) sorting on UCS2/UTF-16 Code Units would not > achieve the same goal (although the result would differ). > > > > > > > >> > > > >> Your claim about uppercase Unicode escapes is > incorrect, there is no such requirement: > > > >> > > > >> https://tools.ietf.org/html/rfc8259#section-7 > > > >> > > > >> I don't recall ever making a claim about uppercase > Unicode escapes, other than observing that it is the preferred form for > examples in the JSON RFCs... what are you talking about? > > > > > > > > You're right, I found it it in the > https://gibson042.github.io/canonicaljson-spec/#changelog > > > > > > > > Thanx, > > > > Anders > > > > > > > > _______________________________________________ > > > > es-discuss mailing list > > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> <mailto: > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>> > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > _______________________________________________ > > > es-discuss mailing list > > > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>> > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
