[Json] [Errata Verified] RFC7159 (4336)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 15 April 2015 01:57 UTC

To: martinpain@uk.ibm.com, tbray@textuality.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20150415015716.71675180207@rfc-editor.org>
Date: Tue, 14 Apr 2015 18:57:16 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/RG9kyWnrnkzb6vBRqSBsjSS05_s>
Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, json@ietf.org
Subject: [Json] [Errata Verified] RFC7159 (4336)
Precedence: list

The following errata report has been verified for RFC7159,
"The JavaScript Object Notation (JSON) Data Interchange Format". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4336

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Martin Pain <martinpain@uk.ibm.com>
Date Reported: 2015-04-14
Verified by: Barry Leiba (IESG)

Section: Appendix A

Original Text
-------------
[NO MENTION OF SECTION 3 OF RFC 4627]

Corrected Text
--------------
   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.

--------------------------------------
RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis)
--------------------------------------
Title               : The JavaScript Object Notation (JSON) Data Interchange Format
Publication Date    : March 2014
Author(s)           : T. Bray, Ed.
Category            : PROPOSED STANDARD
Source              : JavaScript Object Notation
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

[Json] [Editorial Errata Reported] RFC7159 (4336) RFC Errata System
[Json] [Errata Verified] RFC7159 (4336) RFC Errata System