Re: [Json] I-JSON

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" <lhotka@nic.cz <mailto:lhotka@nic.cz>> wrote:
>
>
>     > On 14 Nov 2016, at 13:03, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> wrote:
>     >
>     > 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.
>
>     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?
>     >
>     >
>     > --
>     > Mark Nottingham   https://www.mnot.net/
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > json mailing list
>     > json@ietf.org <mailto:json@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>
>     --
>     Ladislav Lhotka, CZ.NIC Labs
>     PGP Key ID: E74E8C0C
>
>
>
>
>     _______________________________________________
>     json mailing list
>     json@ietf.org <mailto:json@ietf.org>
>     https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>