rfc8259.original   rfc8259.txt 
JSONbis T. Bray, Ed. Internet Engineering Task Force (IETF) T. Bray, Ed.
Internet-Draft Textuality Request for Comments: 8259 Textuality
Obsoletes: 7159 (if approved) July 17, 2017 Obsoletes: 7159 August 2017
Intended status: Standards Track Category: Standards Track
Expires: January 18, 2018 ISSN: 2070-1721
The JavaScript Object Notation (JSON) Data Interchange Format The JavaScript Object Notation (JSON) Data Interchange Format
draft-ietf-jsonbis-rfc7159bis-04
Abstract Abstract
JavaScript Object Notation (JSON) is a lightweight, text-based, JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from language-independent data interchange format. It was derived from
the ECMAScript Programming Language Standard. JSON defines a small the ECMAScript Programming Language Standard. JSON defines a small
set of formatting rules for the portable representation of structured set of formatting rules for the portable representation of structured
data. data.
This document removes inconsistencies with other specifications of This document removes inconsistencies with other specifications of
JSON, repairs specification errors, and offers experience-based JSON, repairs specification errors, and offers experience-based
interoperability guidance. interoperability guidance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 18, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8259.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 21
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Specifications of JSON . . . . . . . . . . . . . . . . . 3 1.2. Specifications of JSON . . . . . . . . . . . . . . . . . 3
1.3. Introduction to This Revision . . . . . . . . . . . . . . 4 1.3. Introduction to This Revision . . . . . . . . . . . . . . 4
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. String and Character Issues . . . . . . . . . . . . . . . . . 8 8. String and Character Issues . . . . . . . . . . . . . . . . . 8
8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 8 8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 8
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9 8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9 8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . 12
15.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
JavaScript Object Notation (JSON) is a text format for the JavaScript Object Notation (JSON) is a text format for the
serialization of structured data. It is derived from the object serialization of structured data. It is derived from the object
literals of JavaScript, as defined in the ECMAScript Programming literals of JavaScript, as defined in the ECMAScript Programming
Language Standard, Third Edition [ECMA-262]. Language Standard, Third Edition [ECMA-262].
JSON can represent four primitive types (strings, numbers, booleans, JSON can represent four primitive types (strings, numbers, booleans,
and null) and two structured types (objects and arrays). and null) and two structured types (objects and arrays).
A string is a sequence of zero or more Unicode characters [UNICODE]. A string is a sequence of zero or more Unicode characters [UNICODE].
Note that this citation references the latest version of Unicode Note that this citation references the latest version of Unicode
rather than a specific release. It is not expected that future rather than a specific release. It is not expected that future
changes in the UNICODE specification will impact the syntax of JSON. changes in the Unicode specification will impact the syntax of JSON.
An object is an unordered collection of zero or more name/value An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number, pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array. boolean, null, object, or array.
An array is an ordered sequence of zero or more values. An array is an ordered sequence of zero or more values.
The terms "object" and "array" come from the conventions of The terms "object" and "array" come from the conventions of
JavaScript. JavaScript.
JSON's design goals were for it to be minimal, portable, textual, and JSON's design goals were for it to be minimal, portable, textual, and
a subset of JavaScript. a subset of JavaScript.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The grammatical rules in this document are to be interpreted as The grammatical rules in this document are to be interpreted as
described in [RFC5234]. described in [RFC5234].
1.2. Specifications of JSON 1.2. Specifications of JSON
This document updates [RFC4627], which describes JSON and registers This document replaces [RFC7159]. RFC 7159 obsoleted RFC 4627, which
the media type "application/json". originally described JSON and registered the media type "application/
json".
JSON is also described in [ECMA-404]. JSON is also described in [ECMA-404].
The reference to ECMA-404 in the previous sentence is normative, not The reference to ECMA-404 in the previous sentence is normative, not
with the usual meaning that implementors need to consult it in order with the usual meaning that implementors need to consult it in order
to understand this document, but to emphasize that there are no to understand this document, but to emphasize that there are no
inconsistencies in the definition of the term "JSON text" in any of inconsistencies in the definition of the term "JSON text" in any of
its specifications. Note, however, that ECMA-404 allows several its specifications. Note, however, that ECMA-404 allows several
practices which this specification recommends avoiding in the practices that this specification recommends avoiding in the
interests of maximal interoperability. interests of maximal interoperability.
The intent is that the grammar is the same between the two documents, The intent is that the grammar is the same between the two documents,
although different descriptions are used. If there a difference is although different descriptions are used. If there is a difference
found between them, ECMA and the IETF will work together to update found between them, ECMA and the IETF will work together to update
both documents. both documents.
If an error is found with either document, the other should be If an error is found with either document, the other should be
examined to see if it has a similar error, and fixed if possible. examined to see if it has a similar error; if it does, it should be
fixed, if possible.
If either document is changed in the future, ECMA and the IETF will If either document is changed in the future, ECMA and the IETF will
work together to ensure that the two documents stay aligned through work together to ensure that the two documents stay aligned through
the change. the change.
1.3. Introduction to This Revision 1.3. Introduction to This Revision
In the years since the publication of RFC 4627, JSON has found very In the years since the publication of RFC 4627, JSON has found very
wide use. This experience has revealed certain patterns, which, wide use. This experience has revealed certain patterns that, while
while allowed by its specifications, have caused interoperability allowed by its specifications, have caused interoperability problems.
problems.
Also, a small number of errata have been reported to RFC4627 (see RFC Also, a small number of errata have been reported regarding RFC 4627
Errata IDs 607 [Err607] and 3607 [Err3607]) and to RFC7159 (see RFC (see RFC Errata IDs 607 [Err607] and 3607 [Err3607]) and regarding
Errata IDs [Err3915], [Err4264], and [Err4336]). RFC 7159 (see RFC Errata IDs 3915 [Err3915], 4264 [Err4264], 4336
[Err4336], and 4388 [Err4388]).
This document's goal is to apply the errata, remove inconsistencies This document's goal is to apply the errata, remove inconsistencies
with other specifications of JSON, and highlight practices that can with other specifications of JSON, and highlight practices that can
lead to interoperability problems. lead to interoperability problems.
2. JSON Grammar 2. JSON Grammar
A JSON text is a sequence of tokens. The set of tokens includes six A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names. structural characters, strings, numbers, and three literal names.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
%x20 / ; Space %x20 / ; Space
%x09 / ; Horizontal tab %x09 / ; Horizontal tab
%x0A / ; Line feed or New line %x0A / ; Line feed or New line
%x0D ) ; Carriage return %x0D ) ; Carriage return
3. Values 3. Values
A JSON value MUST be an object, array, number, or string, or one of A JSON value MUST be an object, array, number, or string, or one of
the following three literal names: the following three literal names:
false null true false
null
true
The literal names MUST be lowercase. No other literal names are The literal names MUST be lowercase. No other literal names are
allowed. allowed.
value = false / null / true / object / array / number / string value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null null = %x6e.75.6c.6c ; null
skipping to change at page 6, line 46 skipping to change at page 6, line 46
The representation of numbers is similar to that used in most The representation of numbers is similar to that used in most
programming languages. A number is represented in base 10 using programming languages. A number is represented in base 10 using
decimal digits. It contains an integer component that may be decimal digits. It contains an integer component that may be
prefixed with an optional minus sign, which may be followed by a prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. Leading zeros are not fraction part and/or an exponent part. Leading zeros are not
allowed. allowed.
A fraction part is a decimal point followed by one or more digits. A fraction part is a decimal point followed by one or more digits.
An exponent part begins with the letter E in upper or lower case, An exponent part begins with the letter E in uppercase or lowercase,
which may be followed by a plus or minus sign. The E and optional which may be followed by a plus or minus sign. The E and optional
sign are followed by one or more digits. sign are followed by one or more digits.
Numeric values that cannot be represented in the grammar below (such Numeric values that cannot be represented in the grammar below (such
as Infinity and NaN) are not permitted. as Infinity and NaN) are not permitted.
number = [ minus ] int [ frac ] [ exp ] number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; . decimal-point = %x2E ; .
skipping to change at page 7, line 27 skipping to change at page 7, line 27
int = zero / ( digit1-9 *DIGIT ) int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; - minus = %x2D ; -
plus = %x2B ; + plus = %x2B ; +
zero = %x30 ; 0 zero = %x30 ; 0
This specification allows implementations to set limits on the range This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements and precision of numbers accepted. Since software that implements
IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
generally available and widely used, good interoperability can be available and widely used, good interoperability can be achieved by
achieved by implementations that expect no more precision or range implementations that expect no more precision or range than these
than these provide, in the sense that implementations will provide, in the sense that implementations will approximate JSON
approximate JSON numbers within the expected precision. A JSON numbers within the expected precision. A JSON number such as 1E400
number such as 1E400 or 3.141592653589793238462643383279 may indicate or 3.141592653589793238462643383279 may indicate potential
potential interoperability problems, since it suggests that the interoperability problems, since it suggests that the software that
software that created it expects receiving software to have greater created it expects receiving software to have greater capabilities
capabilities for numeric magnitude and precision than is widely for numeric magnitude and precision than is widely available.
available.
Note that when such software is used, numbers that are integers and 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 are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric sense that implementations will agree exactly on their numeric
values. values.
7. Strings 7. Strings
The representation of strings is similar to conventions used in the C The representation of strings is similar to conventions used in the C
family of programming languages. A string begins and ends with family of programming languages. A string begins and ends with
quotation marks. All Unicode characters may be placed within the quotation marks. All Unicode characters may be placed within the
quotation marks, except for the characters that must be escaped: quotation marks, except for the characters that MUST be escaped:
quotation mark, reverse solidus, and the control characters (U+0000 quotation mark, reverse solidus, and the control characters (U+0000
through U+001F). through U+001F).
Any character may be escaped. If the character is in the Basic Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+0000 through U+FFFF), then it may be Multilingual Plane (U+0000 through U+FFFF), then it may be
represented as a six-character sequence: a reverse solidus, followed represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point. The hexadecimal letters A though encode the character's code point. The hexadecimal letters A through
F can be upper or lower case. So, for example, a string containing F can be uppercase or lowercase. So, for example, a string
only a single reverse solidus character may be represented as containing only a single reverse solidus character may be represented
"\u005C". as "\u005C".
Alternatively, there are two-character sequence escape Alternatively, there are two-character sequence escape
representations of some popular characters. So, for example, a representations of some popular characters. So, for example, a
string containing only a single reverse solidus character may be string containing only a single reverse solidus character may be
represented more compactly as "\\". represented more compactly as "\\".
To escape an extended character that is not in the Basic Multilingual To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a 12-character sequence, Plane, the character is represented as a 12-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as containing only the G clef character (U+1D11E) may be represented as
skipping to change at page 8, line 49 skipping to change at page 8, line 46
escape = %x5C ; \ escape = %x5C ; \
quotation-mark = %x22 ; " quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
8. String and Character Issues 8. String and Character Issues
8.1. Character Encoding 8.1. Character Encoding
When transmitting over a network protocol, or as a payload of a JSON text exchanged between systems that are not part of a closed
network protocol intended to be interpreted as part of a protocol, ecosystem MUST be encoded using UTF-8 [RFC3629].
JSON text MUST be encoded in UTF-8 (Section 3 of [UNICODE]).
Previous specifications of JSON have not required the use of UTF-8 Previous specifications of JSON have not required the use of UTF-8
when transmitting JSON text. However, the vast majority of JSON- when transmitting JSON text. However, the vast majority of JSON-
based software implementations have chosen to use the UTF-8 encoding, based software implementations have chosen to use the UTF-8 encoding,
to the extent that it is the only encoding that achieves to the extent that it is the only encoding that achieves
interoperability. interoperability.
Implementations MUST NOT add a byte order mark (U+FEFF) to the Implementations MUST NOT add a byte order mark (U+FEFF) to the
beginning of a networked-transmitted JSON text. In the interests of beginning of a networked-transmitted JSON text. In the interests of
interoperability, implementations that parse JSON texts MAY ignore interoperability, implementations that parse JSON texts MAY ignore
skipping to change at page 10, line 18 skipping to change at page 10, line 14
of numbers. An implementation may set limits on the length and of numbers. An implementation may set limits on the length and
character contents of strings. character contents of strings.
10. Generators 10. Generators
A JSON generator produces JSON text. The resulting text MUST A JSON generator produces JSON text. The resulting text MUST
strictly conform to the JSON grammar. strictly conform to the JSON grammar.
11. IANA Considerations 11. IANA Considerations
The MIME media type for JSON text is application/json. The media type for JSON text is application/json.
Type name: application Type name: application
Subtype name: json Subtype name: json
Required parameters: n/a Required parameters: n/a
Optional parameters: n/a Optional parameters: n/a
Encoding considerations: binary Encoding considerations: binary
Security considerations: See [THIS DOC], Section 12. Security considerations: See RFC 8259, Section 12
Interoperability considerations: Described in [THIS DOC] Interoperability considerations: Described in RFC 8259
Published specification: [THIS DOC] Published specification: RFC 8259
Applications that use this media type: Applications that use this media type:
JSON has been used to exchange data between applications written JSON has been used to exchange data between applications written
in all of these programming languages: ActionScript, C, C#, in all of these programming languages: ActionScript, C, C#,
Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript,
Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and
Scheme. Scheme.
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): .json File extension(s): .json
Macintosh file type code(s): TEXT Macintosh file type code(s): TEXT
Person & email address to contact for further information: Person & email address to contact for further information:
IESG IESG
<iesg@ietf.org> <iesg@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none
Restrictions on usage: none
Author: Author:
Douglas Crockford Douglas Crockford
<douglas@crockford.com> <douglas@crockford.com>
Change controller: Change controller:
IESG IESG
<iesg@ietf.org> <iesg@ietf.org>
Note: No "charset" parameter is defined for this registration. Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients. Adding one really has no effect on compliant recipients.
12. Security Considerations 12. Security Considerations
Generally, there are security issues with scripting languages. JSON Generally, there are security issues with scripting languages. JSON
is a subset of JavaScript but excludes assignment and invocation. is a subset of JavaScript but excludes assignment and invocation.
skipping to change at page 12, line 41 skipping to change at page 12, line 38
] ]
Here are three small JSON texts containing only values: Here are three small JSON texts containing only values:
"Hello world!" "Hello world!"
42 42
true true
14. Contributors 14. References
RFC 4627 was written by Douglas Crockford. This document was
constructed by making a relatively small number of changes to that
document; thus, the vast majority of the text here is his.
15. References 14.1. Normative References
15.1. Normative References
[ECMA-404] [ECMA-404]
Ecma International, "The JSON Data Interchange Format", Ecma International, "The JSON Data Interchange Format",
Standard ECMA-404, October 2013, <http://www.ecma- Standard ECMA-404, October 2013, <http://www.ecma-
international.org/publications/standards/Ecma-404.htm>. international.org/publications/standards/Ecma-404.htm>.
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic",
Standard 754, August 2008, IEEE 754.
<http://grouper.ieee.org/groups/754/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", [UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
15.2. Informative References 14.2. Informative References
[ECMA-262] [ECMA-262]
Ecma International, "ECMAScript Language Specification, Ecma International, "ECMAScript Language Specification",
Third Edition", Standard ECMA-262, December 1999, Standard ECMA-262, Third Edition, December 1999,
<http://www.ecma-international.org/publications/files/ <http://www.ecma-international.org/publications/files/
ECMA-ST-ARCH/ ECMA-ST-ARCH/
ECMA-262,%203rd%20edition,%20December%201999.pdf>. ECMA-262,%203rd%20edition,%20December%201999.pdf>.
[Err3607] RFC Errata, "Errata ID 3607", RFC 4627, <https://www.rfc- [Err3607] RFC Errata, Erratum ID 3607, RFC 4627,
editor.org/errata/eid3607>. <https://www.rfc-editor.org/errata/eid3607>.
[Err3915] RFC Errata, "Errata ID 7159", RFC 7159, <https://www.rfc- [Err3915] RFC Errata, Erratum ID 3915, RFC 7159,
editor.org/errata/eid3915>. <https://www.rfc-editor.org/errata/eid3915>.
[Err4264] RFC Errata, "Errata ID 7159", RFC 7159, <https://www.rfc- [Err4264] RFC Errata, Erratum ID 4264, RFC 7159,
editor.org/errata/eid4264>. <https://www.rfc-editor.org/errata/eid4264>.
[Err4336] RFC Errata, "Errata ID 7159", RFC 7159, <https://www.rfc- [Err4336] RFC Errata, Erratum ID 4336, RFC 7159,
editor.org/errata/eid4336>. <https://www.rfc-editor.org/errata/eid4336>.
[Err607] RFC Errata, "Errata ID 607", RFC 4627, <https://www.rfc- [Err4388] RFC Errata, Erratum ID 4388, RFC 7159,
editor.org/errata/eid607>. <https://www.rfc-editor.org/errata/eid4388>.
[Err607] RFC Errata, Erratum ID 607, RFC 4627,
<https://www.rfc-editor.org/errata/eid607>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, DOI 10.17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>. <https://www.rfc-editor.org/info/rfc4627>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
Appendix A. Changes from RFC 7159 Appendix A. Changes from RFC 7159
This section lists changes between this document and the text in RFC This section lists changes between this document and the text in RFC
RFC7159. 7159.
o Section 1.2 has been updated to reflect the removal of a JSON o Section 1.2 has been updated to reflect the removal of a JSON
specification from ECMA-262, to make the reference to ECMA-404 specification from ECMA-262, to make ECMA-404 a normative
normative, and to explain the particular meaning of "normative". reference, and to explain the particular meaning of "normative".
o Section 1.3 has been updated to reflect errata filed against o Section 1.3 has been updated to reflect errata filed against RFC
RFC7159, not RFC4627. 7159, not RFC 4627.
o Section 8.1 was changed to require the use of UTF-8 when o Section 8.1 was changed to require the use of UTF-8 when
transmitted over a network. transmitted over a network.
o Section 12 has been updated to increase the precision of the o Section 12 has been updated to increase the precision of the
description of the security risk that follows from using the description of the security risk that follows from using the
ECMAScript "eval()" function. ECMAScript "eval()" function.
o Section 15.1 has been updated to include ECMA 404 as a normative o Section 14.1 has been updated to include ECMA-404 as a normative
reference. reference.
o Section 15.2 has been updated to remove ECMA 404, update the o Section 14.2 has been updated to remove ECMA-404, update the
version of ECMA-262, and refresh the errata list. version of ECMA-262, and refresh the errata list.
Contributors
RFC 4627 was written by Douglas Crockford. This document was
constructed by making a relatively small number of changes to that
document; thus, the vast majority of the text here is his.
Author's Address Author's Address
Tim Bray (editor) Tim Bray (editor)
Textuality Textuality
EMail: tbray@textuality.com Email: tbray@textuality.com
 End of changes. 48 change blocks. 
98 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/