Re: [jose] Performance of Canonical JSON

Without addressing the rest of the question, your assertion that a
hypothetical JSON working group approach to c14n would take a schema-driven
approach is unsupported by evidence and I think very unlikely.  If only
because there is no JSON schema technology that has anything like consensus
support.

On Sun, Dec 9, 2018 at 2:22 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2018-12-07 19:25, Bret Jordan wrote:
> > Thanks for the test data. Are you going to request a side meeting for
> Prague?
>
> That's a good question. Since few have read the existing (somewhat
> constrained), serialization-only proposal [1], I'm considering other
> alternatives [4,5]
>
> As you know REST [2] is currently held as the only "real" way architecting
> Web applications.  In spite of that, there is no standard for signing REST
> requests but signed REST requests are still used in the wild including by
> Amazon [3].
>
> A rebooted JSON WG would likely settle on a full-fledged counterpart to
> XML's "CN14" which I have no interest in because it presumes that the
> canonicalization process is schema driven for both parsing and
> serialization, making deployment much more complex.
>
> Anyway, IF there actually is GENUINE interest in a BoF session in Prague,
> could you guys on the list indicate your interest?
>
> Thanx,
> Anders
>
> 1]
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
>
> 2] https://en.wikipedia.org/wiki/Representational_state_transfer
>
> 3]
> https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
>
> 4] https://www.rfc-editor.org/about/independent/
>
> 5] Ignoring the standards process and rather let associated applications
> like https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf
> set a de-facto standard.
>
>
>
> >
> > Bret
> >
> > Sent from my Commodore 128D
> >
> > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> >
> > On Dec 7, 2018, at 9:23 AM, Anders Rundgren <
> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
> wrote:
> >
> >> Since XML Canonicalization has a reputation of not only being brittle
> but also terribly slow, I tested JCS [1] with the following JSON file:
> >> {
> >>   "1": {"f": {"f": "hi","F": 5} ,"\n": 56.0},
> >>   "10": { },
> >>   "": "empty",
> >>   "a": { },
> >>   "111": [ {"e": "yes","E": "no" } ],
> >>   "A": { }
> >> }
> >>
> >> Expected output:
> {"":"empty","1":{"\n":56,"f":{"F":5,"f":"hi"}},"10":{},"111":[{"E":"no","e":"yes"}],"A":{},"a":{}}
> >>
> >> Since JCS only is a serialization concept (parsing is unaffected), I
> compared the execution speed of standard serialization versus canonicalized
> serialization.
> >>
> >> Using https://www.npmjs.com/package/canonicalize the performance
> penalty was about 2.4 compared to JSON.stringify().
> >> Using my homegrown JSON tools written in Java having an integrated
> "canonicalize" serializer option the performance penalty was about 1.4
> >>
> >> Anders
> >>
> >> 1]
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> >>
> >> _______________________________________________
> >> jose mailing list
> >> jose@ietf.org <mailto:jose@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)