Subject: [Json] [Technical Errata Reported] RFC7159 (3984)

From: RFC Errata System <[email-masked]>
Date: Fri, 9 May 2014 00:45:38 -0700 (PDT)

The following errata report has been submitted 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=3984

--------------------------------------
Type: Technical
Reported by: Alain BENEDETTI <[email-masked]>

Section: 7

Original Text
-------------
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

Corrected Text
--------------
unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF

Notes
-----
Section 1 says:
[START QUOTE]
A string is a sequence of zero or more Unicode characters [UNICODE]. Note that this citation references the latest version of Unicode rather than a specific release.
[END QUOTE]

Section 8.2 emphasizes on the characters not allowed by the Unicode norm:
[START QUOTE]
However, the ABNF in this specification allows member names and string values to contain bit sequences that cannot encode Unicode characters; for example, "\uDEAD" (a single unpaired UTF-16 surrogate).
[END QUOTE]

The ABNF cannot at the same time allow non conformant Unicode codepoints (section 7) and states conformance to Unicode (section 1).

Therefore, there is an incoherence that must be fixed between section 1 (and 8.2 that emphasizes it) and section 7. Hence the proposition of modification in section 7.

The other less preferable solution to this fix incoherence in RFC7159 would have been to NOT require Unicode conformance.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

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

---

From: Tim Bray <[email-masked]>
Date: Fri, 9 May 2014 08:44:58 -0700

The description of the erratum is correct as provided, but no change should
be made. The design error in RFC 4627 that allows broken Unicode is a well
known historical artifact and can't be legislated away. Note the
interoperability guidance in 7159, which acknowledges this fact
On May 9, 2014 12:46 AM, "RFC Errata System" <[email-masked]>
wrote:

> A string is a sequence of zero or more Unicode characters [UNICODE]. Note
> that this citation references the latest version of Unicode rather than a
> specific release.
> [END QUOTE]
>
> However, the ABNF in this specification allows member names and string
> values to contain bit sequences that cannot encode Unicode characters; for
> example, "\uDEAD" (a single unpaired UTF-16 surrogate).
> [END QUOTE]
>
> The ABNF cannot at the same time allow non conformant Unicode codepoints
> (section 7) and states conformance to Unicode (section 1).
>
> Therefore, there is an incoherence that must be fixed between section 1
> (and 8.2 that emphasizes it) and section 7. Hence the proposition of
> modification in section 7.
>
> The other less preferable solution to this fix incoherence in RFC7159
> would have been to NOT require Unicode conformance.
>
> Instructions:
> -------------

---

From: Matt Miller <[email-masked]>
Date: Fri, 9 May 2014 10:09:44 -0600

RFC Editor: please reject this erratum.

The WG's consensus was to leave the full range present in the ABNF and
add the interoperability guidance about values outside the Unicode
accepted range.

Thank you,

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On 5/9/14, 1:45 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC7159, "The
> JavaScript Object Notation (JSON) Data Interchange Format".
> 
> -------------------------------------- You may review the report
> below and at: 
> -------------------------------------- Type: Technical Reported by:
> Alain BENEDETTI <[email-masked]>
> 
> Section: 7
> 
> Original Text ------------- unescaped = %x20-21 / %x23-5B /
> %x5D-10FFFF
> 
> Corrected Text -------------- unescaped = %x20-21 / %x23-5B /
> %x5D-D7FF / %xE000-10FFFF
> 
> Notes ----- Section 1 says: [START QUOTE] A string is a sequence of
> zero or more Unicode characters [UNICODE]. Note that this citation
> references the latest version of Unicode rather than a specific
> release. [END QUOTE]
> 
> Section 8.2 emphasizes on the characters not allowed by the Unicode
> norm: [START QUOTE] However, the ABNF in this specification allows
> member names and string values to contain bit sequences that cannot
> encode Unicode characters; for example, "\uDEAD" (a single unpaired
> UTF-16 surrogate). [END QUOTE]
> 
> The ABNF cannot at the same time allow non conformant Unicode
> codepoints (section 7) and states conformance to Unicode (section
> 1).
> 
> Therefore, there is an incoherence that must be fixed between
> section 1 (and 8.2 that emphasizes it) and section 7. Hence the
> proposition of modification in section 7.
> 
> The other less preferable solution to this fix incoherence in
> RFC7159 would have been to NOT require Unicode conformance.
> 
> Instructions: ------------- This errata is currently posted as
> "Reported". If necessary, please use "Reply All" to discuss whether
> it should be verified or rejected. When a decision is reached, the
> verifying party (IESG) can log in to change the status and edit the
> report, if necessary.
> 
> -------------------------------------- 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
>