Interop with systems that use 64b ints is not a .001% issue. On Sun, Mar 18, 2018, 11:40 AM Anders Rundgren < [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]>> > wrote: > > > > On 2018-03-18 15:08, Richard Gibson wrote: > >> On Sunday, March 18, 2018, Anders Rundgren < > [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]> > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
