I think the horse is out of the barn re hashable-vs-canonical. It has (independently) been invented and named canonical JSON many many times, starting 11 years ago.
https://gibson042.github.io/canonicaljson-spec/ https://www.npmjs.com/package/another-json https://www.npmjs.com/package/canonical-json https://www.npmjs.com/package/keyify https://www.npmjs.com/package/canonical-tent-json https://www.npmjs.com/package/content-addressable-json https://godoc.org/github.com/gibson042/canonicaljson-go https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 https://keybase.io/docs/api/1.0/canonical_packings#json https://tools.ietf.org/html/rfc7638#section-3.3 http://wiki.laptop.org/go/Canonical_JSON https://github.com/mirkokiefer/canonical-json https://github.com/davidchambers/CANON "Content Addressable JSON" is a variant of your "hashable JSON" proposal, though. But the "canonicals" seem to vastly outnumber the "hashables". My question for Anders is: do you actually plan to incorporate any feedback into changes to your proposal? Or were you really just looking for us to validate your work, not actually contribute to it? --scott On Fri, Mar 16, 2018 at 3:09 PM, Mike Samuel <[email protected]> wrote: > > > On Fri, Mar 16, 2018 at 3:03 PM, Anders Rundgren < > [email protected]> wrote: > >> On 2018-03-16 19:51, Mike Samuel wrote: >> >>> >>> >>> On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren < >>> [email protected] <mailto:[email protected]>> >>> wrote: >>> >>> On 2018-03-16 19:30, Mike Samuel wrote: >>> >>> 2. Any numbers with minimal changes: dropping + signs, >>> normalizing zeros, >>> using a fixed threshold for scientific notation. >>> PROS: supports whole JSON value-space >>> CONS: less useful for hashing >>> CONS: risks loss of precision when decoders decide based >>> on presence of >>> decimal point whether to represent as double or int. >>> >>> >>> Have you actually looked into the specification? >>> https://cyberphone.github.io/doc/security/draft-rundgren-jso >>> n-canonicalization-scheme.html#rfc.section.3.2.2 < >>> https://cyberphone.github.io/doc/security/draft-rundgren-js >>> on-canonicalization-scheme.html#rfc.section.3.2.2> >>> ES6 has all what it takes. >>> >>> >>> Yes, but other notions of canonical equivalence have been mentioned here >>> so reasons to prefer one to another seem in scope. >>> >> >> Availability beats perfection anytime. This is the VHS (if anybody >> remember that old story) of canonicalization and I don't feel too bad about >> that :-) > > > Perhaps. Any thoughts on my question about the merits of "Hashable" vs > "Canonical"? >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
