RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 12 records.

Status: Reported (10)

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: 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: 7383
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Daniel Tegründe
Date Reported: 2023-03-12

Section 3. Values says:

      false = %x66.61.6c.73.65   ; false

      null  = %x6e.75.6c.6c      ; null

It should say:

      false = %x66.61.6C.73.65   ; false

      null  = %x6E.75.6C.6C      ; null

Notes:

Hex values should be capitalized https://www.rfc-editor.org/rfc/rfc5234#appendix-B.1

Errata ID: 7600
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-11

Section 6 says:

   The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros are not
   allowed.

It should say:

   The representation of numbers is similar to that used in most
   programming languages.  A number is represented in base 10 using
   decimal digits.  It contains an integer component that may be
   prefixed with an optional minus sign, which may be followed by a
   fraction part and/or an exponent part.  Leading zeros in the
   integer component beyond the units digit are not allowed.

Notes:

The original wording about leading zeros contradicts the documented ABNF grammar for JSON numbers in the following cases:
- If the integer component is equal to 0 and the fractional component exists. (Examples: 0.1, 0.001)
- In the exponent part, after the letter E or e or the optional sign. (Example: 1E01)

Errata ID: 7603
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-13

Section 1 says:

   A string is a sequence of zero or more Unicode characters [UNICODE].

It should say:

   A string is a sequence of zero or more Unicode code points [UNICODE].

Notes:

Surrogate code points are not Unicode characters, as explained here: https://www.unicode.org/glossary/#surrogate_character

However, a surrogate code point outside of a surrogate pair is allowed in JSON strings both in escaped and unescaped forms according to the ABNF grammar in section 7 and the warning in section 8.2, despite an UTF-8 incompatibility for the unescaped form. In addition, the original text contradicts ECMA-404 section 9, which states: "A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. "

Errata ID: 7617
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Guillaume Fortin-Debigaré
Date Reported: 2023-08-25

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 parses numbers as rational numbers in
   decimal or scientific notation, they are interoperable in the sense
   that implementations will agree exactly on their numeric values. In
   particular, when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in that
   sense.

Notes:

IEEE 754 does not consider negative zero and positive zero to be the same numeric value, even though it considers them equal. Despite this, JavaScript serializes negative zero as the JSON text "0", which contradicts the original text.

My suggested correction mentions "rational numbers in decimal or scientific notation" since it's never explicitly mentioned in the document how a number should be interpreted when parsed to maximize interoperability. This version addresses that concern at the same time.

Errata ID: 7650
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Lucas Tesson
Date Reported: 2023-09-20

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

It should say:

      string = quotation-mark *json-char quotation-mark

      json-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

Notes:

RFC 5234 Section 2.1 "Rule Naming" notes that "rule names are case insensitive". It is explained that literal text strings enclosed in quotation marks are case insensitive, and have later been clarified by RFC 7405.
In RFC 5234 Appendix B, Section B.1 "Core Rules", the rule "CHAR" is already defined such that it constitutes the core of ABNF, thus no grammar can use those names regarding the previous explanation.

The goal of this errata is to propose an alternative for the "char" rule such that RFC 8259 can provide a valid grammar regarding the ABNF RFCs.

Errata ID: 7673
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Zachary Collier (Zamicol)
Date Reported: 2023-10-11

Section 7 says:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks. All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F).

It should say:

The representation of strings is similar to conventions used in the C family
of programming languages.  A string begins and ends with quotation marks.  All
Unicode characters may be placed within the quotation marks, except for the
characters that MUST be escaped: quotation mark, reverse solidus, and the
control characters (U+0000 through U+001F, U+007F, and U+0080 through
U+009F).

Notes:

There are 33 7-bit control characters, but the JSON RFC only listed 32 by
omitting the inclusion of the last control character in the 7-bit ASCII range,
'del.' However, JSON is not limited to 7-bit ASCII; it is Unicode. Unicode
encompasses 65 control characters from U+0080 to U+009F, totaling an additional
32 characters. The section that currently reads "U+0000 through U+001F" should
include these additional control characters reading as "U+0000 through U+001F,
U+007F, and U+0080 through U+009F"

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 (2)

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.

Errata ID: 7307
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Maxim Iurie
Date Reported: 2023-01-13
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 3 says:

      null  = %x6e.75.6c.6c      ; null 

It should say:

      null  = %x6e.75.6c.6c      ; null without quotation marks for numeric attributes and "null" for string attributes.

Notes:

It is not clear how to encode null values in JSON.
Some are encoding all attributes as "null".
Some are encoding all attributes as null without quotation marks
Some are encoding string attributes as "null" and numeric attributes as null without quotation marks.
https://json.org is mentioning "null". ECMA 262 is mentioning "null" for string and +0F for numeric attributes. However providing zero for a number instead of null is incorrect and provides wrong results (in BI).
--VERIFIER NOTES--
The original specification is clear as such, and this errata would make a change that breaks the format, and is against the original intent of the text.

Report New Errata



Advanced Search