Update mentioned RFC in `json` module

[Viicos]

Documentation

The documentation mentions:

The JSON format is specified by RFC 7159 and by ECMA-404.

However, RFC 7159 was obsoleted by RFC 8259. Should we update the linked RFC?

Linked PRs

• gh-136216: Update JSON RFC references from 7159 to 8259 #144453
• gh-136216: Updated mentioned RFC in json module #149322

[AA-Turner]

What is materially different?

A

[Viicos]

Changes described by the appendix, or see the diff. Not much updates, but generally I think it makes sense to reference the latest RFCs in docs.

[ericvsmith]

I don't see a lot of material differences, but I did not spend a lot of time looking at the encoding section. It makes a difference if the json module complies with the new RFC.

[LamentXU123]

The latest RFC actually don't mention new stuff(or some in encoding), its actually a wording update for the former one. Both Ok for the change or just leave it alone.

[KentaroJay]

Hi @Viicos ! I recently started to contribute. Can I take this?

[AA-Turner]

@KentaroJay as you will note from this discussion, it is unclear if a change is needed, when nothing substantive in the specification is different.

A

[Viicos]

I think it can be beneficial to link to the latest RFC (provided that the json module complies with it, see below) to avoid having users looking at the referenced RFC, only to see that it is superseded by a newer one and then wonders if the json module actually supports it.

With that said, there is actually one interesting change in the latest spec:

Section 8.1 was changed to require the use of UTF-8 when transmitted over a network.

We currently document that:

cpython/Doc/library/json.rst

Lines 631 to 635 in c89f76e

	Character Encodings
	^^^^^^^^^^^^^^^^^^^
	The RFC requires that JSON be represented using either UTF-8, UTF-16, or
	UTF-32, with UTF-8 being the recommended default for maximum interoperability.

So this would probably need to be updated. I'm also wondering if it is guaranteed for json.dump(s) to produce UTF-8 strings only.

[ericvsmith]

I agree we should reference the most recent RFC we comply with.

Since the json module doesn't transmit over a network, I don't think it matters what the RFC says in regards to networks. The only places I see str/byte encodings is json.tool and in detect_encoding, called from loads. It's unfortunate that it tries to guess a bytes encoding instead of requiring that it be specified (but that was removed in 3.9, for I assume valid reasons). Since the input is required to be UTF-8, UTF-16, or UTF-32, it looks okay.

json.dump(s) always returns str, so no encoding issues there.

[picnixz]

Note that the module introduction starts with:

JSON (JavaScript Object Notation), specified by RFC 7159 (which obsoletes RFC 4627)

So, we're already mentioning historical RFCs and it wouldn't hurt to mention the latest one. Our module also complies with ECMA 404 which was not normative in RFC 7159.

Since errata indices were also updated, it would be better to link the latest one where those errata are correctly linked.

Finally, the fact that ECMA-262 is no more referenced would be better as we don't rely on the JSON specs defined there (we reference ECMA-404). I haven't looked at ECMA-262 but even if the two specs are identical, better to have a document pruned of unnecessary standards.

[hugovk]

@Viicos Would you like to open a PR?