Found 3 records.

Status: Verified (3)

RFC 7159, "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014

Note: This RFC has been obsoleted by RFC 8259

Errata ID: 3915
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2014-03-07
Verifier Name: Pete Resnick
Date Verified: 2014-05-16

Section 12 says:

   Since JSON's syntax is borrowed from JavaScript, it is possible to
   use that language's "eval()" function to parse JSON texts.

It should say:

   Since JSON's syntax is borrowed from JavaScript, it is possible to
   use that language's "eval()" function to parse most (but not all)
   JSON texts.

Notes:

This wording may be construed as meaning that every compliant JSON text is parseable as JavaScript, which is not the case: <http://timelessrepo.com/json-isnt-a-javascript-subset>. (Actually I would prefer this to be stated clearly elsewhere in the document, e.g. where it says "JSON's design goals were for it to be [...] a subset of JavaScript".)

--VERIFIER NOTES--
As per the above citation, there are characters (in particular line terminators like U+2028 and U+2029) which are permissible in JSON but not permissible in JavaScript. The corrected text makes this clearer.

Errata ID: 4264
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Federico do Pino
Date Reported: 2015-02-05
Verifier Name: Barry Leiba
Date Verified: 2015-03-01

Section 15.2 says:

   [Err3607]  RFC Errata, Errata ID 3607, RFC 3607,
              <http://www.rfc-editor.org>.

   [Err607]   RFC Errata, Errata ID 607, RFC 607,
              <http://www.rfc-editor.org>.

It should say:

   [Err3607]  RFC Errata, Errata ID 3607, for RFC 4627,
              <http://www.rfc-editor.org>.

   [Err607]   RFC Errata, Errata ID 607, for RFC 4627,
              <http://www.rfc-editor.org>.

Notes:

The references point to RFCs by the same numbers as the errata IDs, while the intention was to refer to errata (by the same IDs) reported for the previous JSON RFC, namely RFC 4627. (RFCs 607 and 3607 are completely unrelated.)

The links may also be replaced with direct links to the errata pages, for instance http://www.rfc-editor.org/errata_search.php?eid=607 and http://www.rfc-editor.org/errata_search.php?eid=3607

Errata ID: 4336
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Pain
Date Reported: 2015-04-14
Verifier Name: Barry Leiba
Date Verified: 2015-04-14

Section Appendix A says:

[NO MENTION OF SECTION 3 OF RFC 4627]

It should say:

   o  Removed method of detection of character encoding from
      section 3 "Encoding" of RFC 4627.

       

Notes:

Appendix 1 (listing changes between RFC 4627 and RFC 7159) does not include any comment on the removal of this text from RFC 4627 section 3:

[START QUOTE]
Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
[END QUOTE]


The new section 8.1 "Character encoding" states that:

[START QUOTE]
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32
[END QUOTE]

but, unlike RFC 4627 section 3, it does not say anything about how to distinguish which has been used when parsing a byte string as JSON.


RFC 7159 section 8.1 also says:

[START QUOTE]
Implementations MUST NOT add a byte order mark to the beginning of a
JSON text.
[END QUOTE]

which rules out using a byte order mark for this purpose.


Additionally, RFC 7159 section 11 says:

[START QUOTE]
Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
[END QUOTE]

which rules out one means of communicating which character encoding is in use when communicating JSON over HTTP (namely a charset parameter on the media type), and implies that there is another means of detecting the character encoding, but does not say what it is.


I've reported this as an erratum on the appendix, as I expect there is an existing means of detecting which of the Unicode character encodings are in use, but I was expecting the appendix to reference it as part of an explanation of the removal of the text I quoted from RFC 4627 section 3 but no such explanation is present. It may be the case that the erratum ought to be against section 8.1 to provide a reference there.

Report New Errata