RFC Errata
Found 6 records.
Status: Reported (5)
RFC 8259, "The JavaScript Object Notation (JSON) Data Interchange Format", December 2017
Source of RFC: jsonbis (art)
Errata ID: 5218
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vasiliy Faronov
Date Reported: 2017-12-28
Section 12 says:
JSON is a subset of JavaScript
It should say:
JSON is nearly a subset of JavaScript
Notes:
JSON is not a subset of JavaScript: there are syntactically valid JSON texts that are not syntactically valid JavaScript. Namely, JSON strings can contain unescaped U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR characters, while JavaScript string literals cannot. Thus, a sequence of characters U+0022 U+2028 U+0022 matches this RFC's 'string' production, but does not match ECMA-262's 'Expression' production.
Errata ID: 5355
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anders Rundgren
Date Reported: 2018-05-10
Section 6 says:
Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.
It should say:
Note that when such software is used, numbers that are integers and are in the range [-(2**53), (2**53)] are interoperable in the sense that implementations will agree exactly on their numeric values.
Notes:
The limit is presumably derived from ECMAScript which says:
"The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value"
However, Number.MAX_SAFE_INTEGER is 9007199254740991 ((2*53)-1) making n+1 (2**53) the largest exactly representable Number value
Errata ID: 5853
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Luca BRUNO
Date Reported: 2019-09-05
Section 11 says:
Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
It should say:
Note: No "charset" parameter is defined for this registration.
JSON text is encoded as described in RFC 8259, Section 8.1.
Notes:
Last sentence of last note of section 11 should be amended, as it introduces confusion by going against other explicit statements, like the followings:
* RFC8259 sect. 8.1 defines that inner encoding is UTF-8
* RFC8259 sect. 11 defines no formal (optional/required) parameters for this registered type
* RFC6838 sect. 4.2.1 defines the common usage of a "charset" parameter as a "required" one (which isn't the case here)
* RFC6838 sect. 4.2.1 defines that "charset" should not be used if the inner payload already transports charset information (e.g. mandatory UTF-8, which is the case here)
* RFC6838 sect. 4.2.1 defines a "charset" parameter only for subtypes of the "text/*" hierarchy (which isn't the case here)
Errata ID: 5210
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2017-12-16
Throughout the document, when it says:
Internet Engineering Task Force (IETF) T. Bray, Ed. Request for Comments: 8259 Textuality Obsoletes: 7159 December 2017 Category: Standards Track ISSN: 2070-1721
It should say:
Internet Engineering Task Force (IETF) T. Bray, Ed. Request for Comments: 8259 Textuality STD: 90 December 2017 Obsoletes: 7159 Category: Standards Track ISSN: 2070-1721
Notes:
Missing "STD" entry in boilerplate.
Errata ID: 5318
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joakim Erdfelt
Date Reported: 2018-04-04
Section 7 says:
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
It should say:
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-2E / %x30-5B / %x5D-10FFFF
Notes:
The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence.
Status: Rejected (1)
RFC 8259, "The JavaScript Object Notation (JSON) Data Interchange Format", December 2017
Source of RFC: jsonbis (art)
Errata ID: 6208
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Golden
Date Reported: 2020-06-10
Rejected by: Barry Leiba
Date Rejected: 2020-06-10
Section 8.1 says:
In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.
It should say:
In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.
Notes:
The original line is copied from previous RFCs that specifically allowed alternate encodings. In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction. By omission, readers may conclude that the *only* option for a BOM is to ignore or error.
--VERIFIER NOTES--
This is asking to revisit what we have consensus on, not a report of an error in the RFC.
The working group had extensive discussions on BOMs, and chose this particular working purposefully.