RFC8259 also says that it allows implementations to reject strings that contain the character 'm', or to reject objects containing array values.
> An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.
But those are not good ideas, and neither is rejecting numbers that are explicitly allowed by the grammar, but happen to be bigger than 9007199254740992.
There also appears to be a contradiction between these directives:
> A JSON parser MUST accept all texts that conform to the JSON grammar.
> An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.
Helpfully, the RFC itself specifies which one should win:
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The discussion of limiting number values glosses over a pretty big logical hole:
> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
Of course, integer values of more than 54 bits are also generally available and widely used. A JSON number such as 36028797018963968 does not suggest that it expects receiving software to have any greater capability for numeric magnitude or precision than is widely available. The actual reason for the mention of integer value restrictions is not discussed, but it is mentioned earlier in the RFC:
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
These goals were not achieved, but they are still corrupting the discussion of numeric values. This RFC is a dog's breakfast. Writing "arbitrary noncompliance will be allowed" makes a mockery of the idea of a standard, and according to its own terms, the document does not even allow the restrictions it claims to allow. This document doesn't do anything except attempt to legitimate any and all existing or future "JSON parsers". There is no JSON data which, according to the lowercased restriction allowances, can be guaranteed to be accepted by a "compliant" JSON parser.
It doesn't reject those numbers, but it doesn't preserve the value across encoding/decoding. And this is not limited to JSON parsers for Javascript, it's quite hard to find a C library that doesn't have the 2^53 limitation.
Regarding limitations on text size, you can always return an out of memory error. As long as it's not a _parsing_ error, it's technically fine, you are still accepting all texts that conform to the JSON grammar but telling the client that there's not enough memory to store the parsed output.
> An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.
But those are not good ideas, and neither is rejecting numbers that are explicitly allowed by the grammar, but happen to be bigger than 9007199254740992.
There also appears to be a contradiction between these directives:
> A JSON parser MUST accept all texts that conform to the JSON grammar.
> An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.
Helpfully, the RFC itself specifies which one should win:
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The discussion of limiting number values glosses over a pretty big logical hole:
> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
Of course, integer values of more than 54 bits are also generally available and widely used. A JSON number such as 36028797018963968 does not suggest that it expects receiving software to have any greater capability for numeric magnitude or precision than is widely available. The actual reason for the mention of integer value restrictions is not discussed, but it is mentioned earlier in the RFC:
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
These goals were not achieved, but they are still corrupting the discussion of numeric values. This RFC is a dog's breakfast. Writing "arbitrary noncompliance will be allowed" makes a mockery of the idea of a standard, and according to its own terms, the document does not even allow the restrictions it claims to allow. This document doesn't do anything except attempt to legitimate any and all existing or future "JSON parsers". There is no JSON data which, according to the lowercased restriction allowances, can be guaranteed to be accepted by a "compliant" JSON parser.