1. 4
  1.  

  2. 2

    I’m confused. What’s the point of this RFC? Isn’t it just referencing the JSON RFC in almost every section? What makes I-JSON different than regular JSON, apart from the recommendation of storing timestamps in ISO 8601 format?

    1. 1

      Also important is the requirement that order of keys in objects be ignored. I’ve had to use a few JSON APIs where order is significant, and they’re a royal pain to deal with in languages/libraries that convert JSON objects to hash-table-based collections, such as NSJSONSerialization in Objective-C and Swift.

      1. 1

        It disallows repeated keys in objects, which is otherwise allowed in both the JSON RFC and ECMA-404.

        1. 1

          Some other subsets require the values of key: value pairs to have the same “type/shape”. I note I-JSON provides no such restriction.

        2. 1

          Why are you confused, it’s explained clearly in section 1 and 2. e.g., all strings are invalid UTF-8 right, when sending numbers, one shouldn’t expect very high precision and encode them as string if necessary

        3. 2

          This is from 2015 so I guess there wasn’t a lot of uptake?

          1. 4

            Loads of stuff was using a restricted subset of JSON similar to this from the very beginning. I’d bet most JSON APIs use exclusively UTF-8, no invalid unicode, no duplicate keys, make sure to use strings for numbers which may not be representable in 64-bit floats, send binary data as base64-encoded strings, follow the must-ignore policy, etc. It’s just nice to have this stuff standardized, so that people can validate that their JSON parsers accept everything in I-JSON and protocol designers can ensure that they only output I-JSON.

            I’d bet that if we analyzed all JSON web traffic, we’d find that a huge amount of it follows I-JSON (though probably mostly unintentionally).

            1. 1

              given that all valid i-json is valid json, you’ll might never know :-)

            2. 2

              The “I” is for “lowest common denominator “.

              1. 1

                Amazon Ion is very well thought out, and very related. https://amzn.github.io/ion-docs/

                1. 2

                  I agree, but it’s a superset of JSON, where I-JSON is a subset. Different use cases, I think.