JSON supports arbitrary precision numbers that can't be properly represented as 64 bit floats. This includes numbers like eg. 1e9999 or 1/1e9999.
On Sun, 18 Mar 2018, 15:30 Anders Rundgren, <[email protected]> wrote: > On 2018-03-18 15:08, Richard Gibson wrote: > > On Sunday, March 18, 2018, Anders Rundgren <[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/ >> <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] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
