Subject: [Json] JSON or I-JSON?

From: Pete Cordell <[email-masked]>
Date: Fri, 26 Feb 2021 11:02:24 +0000

Quick question if I may...

When defining new IETF standards that want to use JSON, are they 
referencing JSON (RFC8259) or I-JSON (RFC7493)?

Thanks,

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Feb 2021 13:03:40 +0100

> When defining new IETF standards that want to use JSON, are they referencing JSON (RFC8259) or I-JSON (RFC7493)?

The answer requires Science (grep through rfc8[3-9]??.txt, so no-one references 7159):

7493 only
	8259 only
		both 7493 and 8259
--------------------------------------
	rfc8366.txt
	rfc8414.txt
	rfc8416.txt
	rfc8427.txt
	rfc8428.txt
rfc8460.txt
	rfc8485.txt
	rfc8520.txt
	rfc8522.txt
	rfc8555.txt
	rfc8572.txt
	rfc8576.txt
		rfc8610.txt
	rfc8618.txt
		rfc8620.txt
	rfc8628.txt
	rfc8639.txt
	rfc8688.txt
	rfc8693.txt
	rfc8725.txt
	rfc8727.txt
rfc8734.txt
	rfc8742.txt
	rfc8743.txt
	rfc8747.txt
	rfc8783.txt
		rfc8785.txt
	rfc8790.txt
		rfc8801.txt
	rfc8805.txt
	rfc8827.txt
	rfc8844.txt
rfc8877.txt
	rfc8895.txt
	rfc8896.txt
	rfc8908.txt
	rfc8921.txt
		rfc8927.txt
	rfc8935.txt
	rfc8936.txt
		rfc8941.txt
		rfc8949.txt
	rfc8977.txt

No indent is 7493 only, one indent is 8259 only, and double indent is both.
(Of course, RFC 8610 and RFC 8949 reference both, one for the JSON format and one for the I-JSON limitations.)

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 26 Feb 2021 13:49:39 +0100

> referencing JSON (RFC8259) or I-JSON (RFC7493)?

If the standard-to-be is supposed to interoperate with browsers and node.js the only viable option is RFC7493.

If the standard-to-be also targets the financial market, further constraints apply since floating point arithmetic is ill-suited for monetary operations. E.g. a monetary amount of 46.99 should be represented in JSON as the string "46.99".

Anders

---

From: John Cowan <[email-masked]>
Date: Fri, 26 Feb 2021 08:59:47 -0500

On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren <
[email-masked]> wrote:

> If the standard-to-be is supposed to interoperate with browsers and
> node.js the only viable option is RFC7493.
>
> If the standard-to-be also targets the financial market, further
> constraints apply since floating point arithmetic is ill-suited for
> monetary operations. E.g. a monetary amount of 46.99 should be represented
> in JSON as the string "46.99".
>

RFC 8259 incorporates all of the restrictions of 7493 as interoperability
warnings, including the one above.  That way it stays compatible with
ECMA-404 (which has no such restrictions or warnings) but still steers you
away from the dark corners of JSON.

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
The Imperials are decadent, 300 pound free-range chickens (except they have
teeth, arms instead of wings, and dinosaurlike tails).  --Elyse Grasso

---

From: Pete Cordell <[email-masked]>
Date: Fri, 26 Feb 2021 14:44:43 +0000

> The answer requires Science (grep through rfc8[3-9]??.txt, so no-one references 7159):
...
> (Of course, RFC 8610 and RFC 8949 reference both, one for the JSON format and one for the I-JSON limitations.)

Many thanks, Carsten.

I noticed a few 8259 only ones mentioned it under "Informative 
References" (not Normative) and others were only interested in the MIME 
type registration parts.  So it's perhaps not so surprising that 7493 is 
not as prevalent as you might at first hope.

I guess which you reference of 7493 and 8259 may also depend on which 
end of the Postel Principle you are on :-)

Pete.

---

From: Pete Cordell <[email-masked]>
Date: Fri, 26 Feb 2021 14:55:23 +0000

On 26/02/2021 13:59, John Cowan wrote:
> 
> 
> On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     monetary operations. E.g. a monetary amount of 46.99 should be
>     represented in JSON as the string "46.99".
> 
> 
> RFC 8259 incorporates all of the restrictions of 7493 as 
> interoperability warnings, including the one above.  That way it stays 
> compatible with ECMA-404 (which has no such restrictions or warnings) 
> but still steers you away from the dark corners of JSON.

RFC 8259 tells you "that way lies madness" but doesn't actually tell you 
to not to go that way!  RFC 7493 makes it explicit not to go that way 
for those that might otherwise say "well you didn't tell me not to...".

Pete.

---

From: Tim Bray <[email-masked]>
Date: Fri, 26 Feb 2021 07:03:12 -0800

I personally would use I-JSON if possible because it has useful MUSTs in it
to help resolve arguments between implementors.  [But then, I edited the
RFC, so I would.]  There's one downside, which is that as far as I know,
there's little software that actually enforces the I-JSON constraints.

On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell <[email-masked]> wrote:

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

---

From: David Kemp <[email-masked]>
Date: Fri, 26 Feb 2021 12:41:00 -0500

Most of the I-JSON constraints are good for interoperability, and as Anders
points out, the lack of a distinct Integer type means that some
applications must use String rather than Number to represent Integers.  But
section 4.2 ("must-ignore") is anathema to security, and the fact that that
is not even discussed in RFC 7493's security considerations is negligent.

If you are designing a protocol that uses, for example, Reputons (
https://tools.ietf.org/html/draft-ietf-repute-media-type-13#section-3.1),
and a Reputon can contain megabytes of malware, or mpegs of cats being
cute, or 14th century pornography (
https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/TestData/slpf%2Bacme/commands/bad/create_poetry.json),
that isn't necessarily a good thing for the Internet.

Dave

On Fri, Feb 26, 2021 at 10:03 AM Tim Bray <[email-masked]> wrote:

> I personally would use I-JSON if possible because it has useful MUSTs in
> it to help resolve arguments between implementors.  [But then, I edited the

---

From: John Cowan <[email-masked]>
Date: Fri, 26 Feb 2021 17:12:18 -0500

On Fri, Feb 26, 2021 at 12:41 PM David Kemp <[email-masked]> wrote:

> that isn't necessarily a good thing for the Internet.

Nevertheless, there are many contexts where must-ignore is entirely
appropriate.  If I am checking your ID card against a list of authorized
visitors, all I need to know is how to find your picture and your name:
whatever other fields may be present are quite irrelevant to me.  (Not
always so easy: probably a hundred traffic tickets were written in Ireland
in 2006-09 in the name of Prawo Jazdy, which is, alas, merely the Polish
for "driver's license".)

In any case, simple limitations on the length or nesting depth of a
structured document should be enough to eliminate all the problems you
mention.

John Cowan          http://vrici.lojban.org/~cowan        [email-masked]
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2021 18:14:33 -0500

> there's little software that actually enforces the I-JSON constraints.

I take I-JSON as giving a concrete example of how to be conservative in
what you send.

I also use it in some of my stuff to be hyper-restrictive in what is
accepted for purposes of conformance testing (and the corresponding
generator is liberal in what it sends).