RFC 7493: The I-JSON Message Format
RFC 7493: The I-JSON Message Format
datatracker.ietf.org
RFC 7493: The I-JSON Message Format
17 comments
-
-
-
Ok.
-
-
Tbh this is a programming community. While yes, a quick summary would not have gone amiss, I don't fault OP for not including it. RFCs are often pretty dry but this one is reasonably straightforward as a subset of JSON to reduce some ambiguity.
-
Imo the only ones that should feel bad about it are those upvoting it.
Edit: lemmy is mostly low effort stuff and not interesting discussions. So while this post provides nothing of value that is something the voting system is supposed to handle
-
-
Why restrict to 54-bit signed integers? Is there some common language I'm not thinking of that has this as its limit?
Edit: Found it myself, it's the range where you can store an integer in a double precision float without error. I suppose that makes sense for maximum compatibility, but feels gross if we're already identifying value types. I don't come from a web-dev/js background, though, so maybe it makes more sense there.
-
Why restrict to 54-bit signed integers?
Because
numberis a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.Meaning, it's the highest integer precision that a double-precision object can express.
I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.
It's not about compatibility. It's because JSON only has a
numbertype which covers both floating point and integers, andnumberis implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer. -
I didn't think you realize just how much code is written in JavaScript these days.
-
-
Just skimmed but seems like a decent idea. Not that I've knowingly run into issues parsing JSON too much
-
It's from 2015, so its probably what you are doing anyway
-
It’s from 2015, so its probably what you are doing anyway
No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.
Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth
-
-
17 comments
A summary:
An old proposal (2015, not sure why OP posted it now), that basically proposes to put some more standards and limitations around JSON formatting to make it more predictable. Most of it seems pretty reasonable:
It recommends:
Honestly, the only part of this I dislike is the order of keys not mattering. I get that in a bunch of languages they use dictionary objects that don't preserve order, but backend languages have a lot more headroom to adapt and create objects that can, vs making a JavaScript thread loop over an object an extra time to reorder it every time it receives data.
Personally, I prefer duplicate keys to be eaten by the parser but I can see how it'd be beneficial to prevent them.
I'm honestly unsure if they intend the 'must-ignore' policy to mean to eat duplicate keys without erroring, or just to eat keys that are unexpected based on some contract or schema....