Re: [Json] JSON for Internet messages

[Tim Bray <[e-mail]>]

On Wed, Jul 3, 2013 at 10:15 AM, John Cowan <[e-mail]> wrote:

> Tim Bray scripsit:
>


> > Also, I’ve never encountered a scenario where the messages were of
> > sufficient size that anyone gave a rat’s ass about streaming.
>
> Well, at least eight programmers have taken the trouble to write
> such parsers


Fair enough. If they can’t write them in such a way as to avoid duplicates,
they are NOT USABLE for application-level message passing, because the only
use for JSON objects is sending a hash-table (or equivalent) from my
computer to a hash-table (or equivalent) on yours, and if there are dupes,
that's either a serious bug or a malicious attack on, for example, a JOSE
header where they’re trying to fake out the algorithm selection. So parsers
that potentially emit dupes can’t comply with the RFC that I want to
exist.  Acceptable cost.



> > - All JSON messages MUST be encoded in valid UTF-8.
> > - All numbers MUST be of precision < 2**53 (use strings for your big
> crypto
> > numbers)
>
> Better: All numbers MUST be representable as IEEE 754:2008 binary
> 64-bit floats.
>

I think my expression of the constraint is more readable, but I agree that
yours is isomorphic.


>
> > - All JSON objects MUST have unique keys
> > - All JSON messages MUST be either arrays or objects
> > - Software receiving something violating any of these MUSTs has
> encountered
> > conclusive evidence of serious upstream breakage and MUST NOT trust the
> > contents nor act upon them.
>
> The trouble with all this is that They Break Data.


I care -Inf about this.  In my application domain, we cook these up in
memory, we send them, we unpack them at the other end.   I agree, that if
if we impose a new set of rules in a new RFC, previously-existing JSON
might not pass muster as “Internet JSON” or whatever we choose to call it.
It’s still JSON Classic.  Fair trade-off.  -T