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/
<http://gibson042.github.io/canonicaljson-spec/>_
[2]:
http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type
<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
<http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring>
[4]: https://tools.ietf.org/html/rfc8259#section-8.1
<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
<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
