Subject: [Json] I-JSON

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Nov 2016 13:03:01 +0900

It seems like I-JSON is the answer to many of the issues that have cropped up with JSON.

However, as a protocol designer, it's not terribly useful to specify I-JSON, because it's very likely that people will just use their existing JSON tools.

A simple answer might be to define a new media type that has a header that's guaranteed to break a JSON parser prepended, but I-JSON as the body.

It might be that people just strip the header and continue to process as JSON, but they have to actively do that, which may be enough of a bar to discourage it (and encourage I-JSON tools to bloom).

Of course, we could define a syntax that's more deeply incompatible with JSON. Not sure if that's necessary, though.

Thoughts? 

--
Mark Nottingham   https://www.mnot.net/

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 14 Nov 2016 07:23:15 +0100

On 2016-11-14 05:03, Mark Nottingham wrote:
> However, as a protocol designer, it's not terribly useful to specify I-JSON,
 > because it's very likely that people will just use their existing JSON tools.
>
> A simple answer might be to define a new media type that has a header that's
 > guaranteed to break a JSON parser prepended, but I-JSON as the body.
>
> It might be that people just strip the header and continue to process as JSON,
 > but they have to actively do that, which may be enough of a bar to discourage it (and encourage I-JSON tools to bloom).
>

The differences between I-JSON and a "sensibly use" of traditional JSON appears to minimal.

If people really want to go further, TJSON is yet another alternative in the workings:
https://www.tjson.org/

Personally I stick to the ES6 definition which is supported by Node.js, Browsers, Java and then some.

That ES6 (in contrast to the other variants) also defines property serialization order makes it highly adapted for cryptographic operations like hashing without any "extras."  A plain JSON.stringify() suffice.

Anders

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 14 Nov 2016 07:44:38 +0100

> Of course, we could define a syntax that's more deeply incompatible with JSON. Not sure if that's necessary, though.

Hi Mark,

As I wrote in the reply to your message I consider ES6 to be a (de-facto) successor to I-JSON.

What's maybe missing is a standardized mapping scheme since lots of people need to emulate additional data types on top of a JSON "string".

The scientific people want 80-bits IEEE
The Java/Python/C# folks want true 64-bit integers
The crypto geeks want really big integers
The financial guys want big decimals

The only change that is needed on the JSON level is making comments a standard so that JSON becomes a logical choice for "config" files as well.
It appears to be close to a de-facto standard already.

Anders

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2016 17:31:04 +0900

> On 14 Nov 2016, at 13:03, Mark Nottingham <[email-masked]> wrote:
> 

My understanding of I-JSON is that it specifically allows people to use their existing JSON tools. In RFC 7951 we use I-JSON and, for example, encode 64-bit integers as strings even though it is awkward and adds extra processing steps in most tools.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Tim Bray <[email-masked]>
Date: Mon, 14 Nov 2016 09:19:10 -0800

I would be very happy if some of the popular JSON tools were to implement
I-JSON modes.

On Nov 14, 2016 12:31 AM, "Ladislav Lhotka" <[email-masked]> wrote:

> > However, as a protocol designer, it's not terribly useful to specify
> I-JSON, because it's very likely that people will just use their existing
> JSON tools.
>
> My understanding of I-JSON is that it specifically allows people to use
> their existing JSON tools. In RFC 7951 we use I-JSON and, for example,
> encode 64-bit integers as strings even though it is awkward and adds extra
> processing steps in most tools.
>
> Lada
>
> >
> > A simple answer might be to define a new media type that has a header
> that's guaranteed to break a JSON parser prepended, but I-JSON as the body.
> >
> > It might be that people just strip the header and continue to process as
> JSON, but they have to actively do that, which may be enough of a bar to
> discourage it (and encourage I-JSON tools to bloom).
> >
> > Of course, we could define a syntax that's more deeply incompatible with
> JSON. Not sure if that's necessary, though.
> >
> > Thoughts?
> >
> >
> > --

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 16 Nov 2016 07:33:01 +0100

On 2016-11-14 18:19, Tim Bray wrote:
> I would be very happy if some of the popular JSON tools were to implement I-JSON modes.

That's easier said than done.

In my maybe-not-so-popular JSON toolkit[1], I-JSON compatible strictness is
achieved by performing JSON syntax checking during parsing but deferring
Number conversions until the actual fetch of a value like getInt("counter").

This presumes that the argument text is preserved in order to flag "weird"
integers like 156.0 which probably isn't the most common way of doing things.

I'm not entirely convinced that the "Must-Ignore Policy" is universally applicable.
For example there are security-related JSON constructs like JOSE where you shouldn't
find any unknown properties.  In the mentioned JSON toolkit this is addressed through:

- checkForUnread() : Explicit deep check for unread properties
- scanAway("property") : Setting a property as "read" (including possible child elements)
           which typically would be applied to specific "extension" sections.

For long-lived sophisticated peer-to-peer applications, I doubt that any of these
measures suffice because unrecognized or unread properties still means that the
sender and receiver are not completely on the same page.

To cope with that I'm looking into publishing objects describing entities' state
wrt to extensions so that a sender never emits "garbage" or may even conclude
(in advance) that it cannot communicate with the intended receiver at all.
For details see "Extending Protocols" in:
https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf

Anders

1] https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/package-summary.html

>
>
> On Nov 14, 2016 12:31 AM, "Ladislav Lhotka" <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     > On 14 Nov 2016, at 13:03, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>
>     --
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>
>
>

---

From: John Cowan <[email-masked]>
Date: Wed, 16 Nov 2016 08:19:11 -0500

On Wed, Nov 16, 2016 at 1:33 AM, Anders Rundgren <
[email-masked]> wrote:

For long-lived sophisticated peer-to-peer applications, I doubt that any of
> these

If the application is truly peer-to-peer (and not master-to-slave), then
there is no reason why the sender and receiver should be on the same page.
If you send me documents full of deep and meaningful facts, and all I do is
count them and post the running total on a Web page, well, you are not the
boss of me.

-- 
John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
I suggest you solicit aid of my followers or learn the difficult art
of mud-breathing.  --Great-Souled Sam