RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.rfc-editor.org/errata/eid4336 below:

RFC Errata Report » RFC Editor

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

Note: This RFC has been obsoleted by RFC 8259

Source of RFC

: json (app)

See Also:

RFC 7159 w/ inline errata

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3