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-tostrin > g-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. > 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. 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. 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?
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
