Note: This RFC has been obsoleted by RFC 8259Source of RFC: json (app)
Errata ID: 4336
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.
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:
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
The new section 8.1 "Character encoding" states that:
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32
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:
Implementations MUST NOT add a byte order mark to the beginning of a
which rules out using a byte order mark for this purpose.
Additionally, RFC 7159 section 11 says:
Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
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.