< draft-ietf-json-rfc4627bis-07.txt   draft-ietf-json-rfc4627bis-08.txt >
JSON Working Group T. Bray, Ed. JSON Working Group T. Bray, Ed.
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Obsoletes: 4627 (if approved) November 06, 2013 Obsoletes: 4627 (if approved) December 04, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: May 10, 2014 Expires: June 07, 2014
The JSON Data Interchange Format The JSON Data Interchange Format
draft-ietf-json-rfc4627bis-07 draft-ietf-json-rfc4627bis-08
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 makes no changes to the definition of JSON; it repairs This document makes no changes to the definition of JSON; it repairs
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2014. This Internet-Draft will expire on June 07, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 15 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . 3
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. String and Character Issues . . . . . . . . . . . . . . . . . 8 8. String and Character Issues . . . . . . . . . . . . . . . . . 8
8.1. Encoding and Detection . . . . . . . . . . . . . . . . . 8 8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 8
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 8 8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 8
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9 8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
15.1. Normative References . . . . . . . . . . . . . . . . . . 12 15.1. Normative References . . . . . . . . . . . . . . . . . . 12
15.2. Informative References . . . . . . . . . . . . . . . . . 12 15.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 4627 . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 4627 . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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 is an update of [RFC4627], which described JSON and This document is an update of [RFC4627], which described JSON and
registered the Media Type "application/json". registered the Media Type "application/json".
A description of JSON in ECMAScript terms appears in version 5.1 of A description of JSON in ECMAScript terms appears in version 5.1 of
the ECMAScript specification [ECMA-262], section 15.12. JSON is also the ECMAScript specification [ECMA-262], section 15.12. JSON is also
described in [ECMA-404]. ECMAscript 5.1 enumerates the differences described in [ECMA-404].
between JSON as described in that specification and in RFC4627. The
most significant is that ECMAScript 5.1 does not require a JSON Text
to be an Array or an Object; thus, for example, the following would
all be valid JSON texts in the ECMAScript context:
o "Hello world!"
o 42
o true
All of the specifications of JSON syntax agree on the syntactic All of the specifications of JSON syntax agree on the syntactic
elements of the language. elements of the language.
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, while wide use. This experience has revealed certain patterns which, while
allowed by its specifications, have caused interoperability problems. allowed by its specifications, have caused interoperability problems.
skipping to change at page 4, line 19 skipping to change at page 4, line 4
allowed by its specifications, have caused interoperability problems. allowed by its specifications, have caused interoperability problems.
Also, a small number of errata have been reported. Also, a small number of errata have been reported.
This revision does not change any of the rules of the specification; This revision does not change any of the rules of the specification;
all texts which were legal JSON remain so, and none which were not all texts which were legal JSON remain so, and none which were not
JSON become JSON. The revision's goal is to fix the errata and JSON become JSON. The revision's goal is to fix the errata and
highlight practices which can lead to interoperability problems. highlight practices which can 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.
A JSON text is a serialized object or array. A JSON text is a serialized value. Note that certain previous
specifications of JSON constrained a JSON text to be an object or an
array. Implementations which generate only objects or arrays where a
JSON text is called for will be interoperable in the sense that all
implementations will accept these as conforming JSON texts.
JSON-text = object / array JSON-text = ws value ws
These are the six structural characters: These are the six structural characters:
begin-array = ws %x5B ws ; [ left square bracket begin-array = ws %x5B ws ; [ left square bracket
begin-object = ws %x7B ws ; { left curly bracket begin-object = ws %x7B ws ; { left curly bracket
end-array = ws %x5D ws ; ] right square bracket end-array = ws %x5D ws ; ] right square bracket
end-object = ws %x7D ws ; } right curly bracket end-object = ws %x7D ws ; } right curly bracket
skipping to change at page 8, line 4 skipping to change at page 8, line 6
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 twelve-character sequence, Plane, the character is represented as a twelve-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
"\uD834\uDD1E". "\uD834\uDD1E".
string = quotation-mark *char quotation-mark string = quotation-mark *char quotation-mark
char = unescaped / char = unescaped /
escape ( escape (
%x22 / ; " quotation mark U+0022 %x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C %x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F %x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008 %x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C %x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A %x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D %x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009 %x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX %x75 4HEXDIG ) ; uXXXX U+XXXX
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. Encoding and Detection 8.1. Character Encoding
JSON text SHALL be encoded in Unicode. The default encoding is JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8. UTF-8, and JSON texts which are encoded in UTF-8 are interoperable in
the sense that they will be read successfully by the maximum number
Since the first two characters of a JSON text will always be ASCII of implementations; there are many implementations which cannot
characters [RFC0020], it is possible to determine whether an octet successfully read texts in other encodings (such as UTF-16 and
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking UTF-32).
at the pattern of nulls in the first four octets.
00 00 00 xx UTF-32BE Implementations have been observed to generate JSON texts prefixed
00 xx 00 xx UTF-16BE with a Byte Order Mark character. While this is not allowed by the
xx 00 00 00 UTF-32LE grammar in this specification, in the interests of interoperability
xx 00 xx 00 UTF-16LE it is RECOMMENDED that implementations which parse JSON texts ignore
xx xx xx xx UTF-8 the presence of a byte order mark rather than treating it as an
error.
8.2. Unicode Characters 8.2. Unicode Characters
When all the strings represented in a JSON text are composed entirely When all the strings represented in a JSON text are composed entirely
of Unicode characters [UNICODE] (however escaped), then that JSON of Unicode characters [UNICODE] (however escaped), then that JSON
text is interoperable in the sense that all software implementations text is interoperable in the sense that all software implementations
which parse it will agree on the contents of names and of string which parse it will agree on the contents of names and of string
values in objects and arrays. values in objects and arrays.
However, the ABNF in this specification allows member names and However, the ABNF in this specification allows member names and
skipping to change at page 9, line 21 skipping to change at page 9, line 24
8.3. String Comparison 8.3. String Comparison
Software implementations are typically required to test names of Software implementations are typically required to test names of
object members for equality. Implementations which transform the object members for equality. Implementations which transform the
textual representation into sequences of Unicode code units, and then textual representation into sequences of Unicode code units, and then
perform the comparison numerically, code unit by code unit, are perform the comparison numerically, code unit by code unit, are
interoperable in the sense that implementations will agree in all interoperable in the sense that implementations will agree in all
cases on equality or inequality of two strings. For example, cases on equality or inequality of two strings. For example,
implementations which compare strings with escaped characters implementations which compare strings with escaped characters
unconverted may incorrectly find that "a\b" and "a\u005Cb" are not unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not
equal. equal.
9. Parsers 9. Parsers
A JSON parser transforms a JSON text into another representation. A A JSON parser transforms a JSON text into another representation. A
JSON parser MUST accept all texts that conform to the JSON grammar. JSON parser MUST accept all texts that conform to the JSON grammar.
A JSON parser MAY accept non-JSON forms or extensions. A JSON parser MAY accept non-JSON forms or extensions.
An implementation may set limits on the size of texts that it An implementation may set limits on the size of texts that it
accepts. An implementation may set limits on the maximum depth of accepts. An implementation may set limits on the maximum depth of
skipping to change at page 9, line 50 skipping to change at page 10, line 4
11. IANA Considerations 11. IANA Considerations
The MIME media type for JSON text is application/json. The MIME 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: 8bit if UTF-8; binary if UTF-16 or UTF-32.
JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON Encoding considerations: binary
is written in UTF-8, JSON is 8bit compatible. When JSON is
written in UTF-16 or UTF-32, the binary content-transfer-encoding
must be used.
Interoperability considerations: Described in this document Interoperability considerations: Described in this document
Published specification: This document Published specification: This document
Applications that use this media type: JSON has been used to Applications that use this media type: JSON has been used to
exchange data between applications written in all of these exchange data between applications written in all of these
programming languages: ActionScript, C, C#, Clojure, ColdFusion, programming languages: ActionScript, C, C#, Clojure, ColdFusion,
Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML,
Perl, PHP, Python, Rebol, Ruby, Scala, and Scheme. Perl, PHP, Python, Rebol, Ruby, Scala, and Scheme.
Additional information: Magic number(s): n/a Additional information: 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: IESG Person & email address to contact for further information: IESG
<iesg@ietf.org <iesg@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Douglas Crockford Author: Douglas Crockford
douglas@crockford.com <douglas@crockford.com>
Change controller: IESG Change controller: IESG
<iesg@ietf.org <iesg@ietf.org>
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.
Since JSON's syntax is borrowed from JavaScript, it is possible to Since JSON's syntax is borrowed from JavaScript, it is possible to
use that language's "eval()" function to parse JSON texts. This use that language's "eval()" function to parse JSON texts. This
generally constitutes an unacceptable security risk, since the text generally constitutes an unacceptable security risk, since the text
could contain executable code along with data declarations. The same could contain executable code along with data declarations. The same
consideration applies in any other programming language in which JSON consideration applies to the use of eval()-like functions in any
texts conform to that language's syntax. other programming language in which JSON texts conform to that
language's syntax.
13. Examples 13. Examples
This is a JSON object: This is a JSON object:
{ {
"Image": { "Image": {
"Width": 800, "Width": 800,
"Height": 600, "Height": 600,
"Title": "View from 15th Floor", "Title": "View from 15th Floor",
"Thumbnail": { "Thumbnail": {
"Url": "http://www.example.com/image/481989943", "Url": "http://www.example.com/image/481989943",
"Height": 125, "Height": 125,
"Width": 100 "Width": 100
}, },
"Animated" : false, "Animated" : false,
"IDs": [116, 943, 234, 38793] "IDs": [116, 943, 234, 38793]
} }
} }
Its Image member is an object whose Thumbnail member is an object and Its Image member is an object whose Thumbnail member is an object and
whose IDs member is an array of numbers. whose IDs member is an array of numbers.
This is a JSON array containing two objects: This is a JSON array containing two objects:
[ [
skipping to change at page 11, line 48 skipping to change at page 11, line 48
"Latitude": 37.371991, "Latitude": 37.371991,
"Longitude": -122.026020, "Longitude": -122.026020,
"Address": "", "Address": "",
"City": "SUNNYVALE", "City": "SUNNYVALE",
"State": "CA", "State": "CA",
"Zip": "94085", "Zip": "94085",
"Country": "US" "Country": "US"
} }
] ]
Here are three small JSON texts containing only values
"Hello world!"
42
true
14. Contributors 14. Contributors
RFC 4627 was written by Douglas Crockford. This document was RFC 4627 was written by Douglas Crockford. This document was
constructed by making a relatively small number of changes to that constructed by making a relatively small number of changes to that
document; thus the vast majority of the text here is his. document; thus the vast majority of the text here is his.
15. References 15. References
15.1. Normative References 15.1. Normative References
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008, [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008,
<http://grouper.ieee.org/groups/754/>. <http://grouper.ieee.org/groups/754/>.
 End of changes. 26 change blocks. 
50 lines changed or deleted 49 lines changed or added

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