< draft-ietf-json-rfc4627bis-04.txt   draft-ietf-json-rfc4627bis-05.txt >
JSON Working Group T. Bray, Ed. JSON Working Group T. Bray, Ed.
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track September 26, 2013 Obsoletes: 4627 (if approved) October 08, 2013
Expires: March 30, 2014 Intended status: Standards Track
Expires: April 11, 2014
The JSON Data Interchange Format The JSON Data Interchange Format
draft-ietf-json-rfc4627bis-04 draft-ietf-json-rfc4627bis-05
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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 March 30, 2014. This Internet-Draft will expire on April 11, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Introduction to This Revision . . . . . . . . . . . . . . 3 1.2. Specifications of JSON . . . . . . . . . . . . . . . . . 3
1.3. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 3 1.3. Introduction to This Revision . . . . . . . . . . . . . . 3
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 4
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Character Model . . . . . . . . . . . . . . . . . . . . . . . 9 7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. String and Character Issues . . . . . . . . . . . . . . . . . 9
8.1. Encoding and Detection . . . . . . . . . . . . . . . . . 9 8.1. Encoding and Detection . . . . . . . . . . . . . . . . . 9
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9 8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9 8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 10
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Normative References . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes in -04 . . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes in -04 . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Changes in -05 . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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]. 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].
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.
skipping to change at page 3, line 17 skipping to change at page 3, line 31
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The grammatical rules in this document are to be interpreted as The grammatical rules in this document are to be interpreted as
described in [RFC4234]. described in [RFC4234].
1.2. Introduction to This Revision 1.2. Specifications of JSON
A description of JSON in ECMAScript terms first appeared in version
5.1 of the ECMAScript specification [ECMA-262], section 15.12. It
includes a description of the differences 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, "Hello world!", "42", and "true" would all
be valid JSON texts in the ECMAScript 5.1 context.
JSON is also described in [ECMA-404].
None of the specifications of JSON syntax disagree on the syntax of
the language.
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 the RFC, 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.
1.3. Changes from RFC 4627 1.4. Changes from RFC 4627
This section lists all changes between this document and the text in This section lists all changes between this document and the text in
RFC 4627. RFC 4627.
o Changed Working Group attribution to JSON Working Group. o Changed Working Group attribution to JSON Working Group.
o Changed title of doc per consensus call at http://www.ietf.org/ o Changed title of document.
mail-archive/web/json/current/msg00736.html
o Applied erratum #607 from RFC 4627 to correctly align the artwork
for the definition of "object".
o Change the reference to [UNICODE] to be be non-version-specific. o Change the reference to [UNICODE] to be be non-version-specific.
o Applied erratum #3607 from RFC 4627 by removing the security o Added a "Specifications of JSON" section.
consideration that begins "A JSON text can be safely passed" and
the JavaScript code that went with that consideration.
o Added Tim Bray as editor.
o Added an "Introduction to this Revision" section. o Added an "Introduction to this Revision" section.
o Added language about duplicate object member names and o Added language about duplicate object member names and
interoperability. interoperability.
o Applied erratum #607 from RFC 4627 to correctly align the artwork
for the definition of "object".
o Changed "as sequences of digits" to "in the grammar below" in
"Numbers" section.
o Added language about number interoperability as a function of o Added language about number interoperability as a function of
IEEE754. Also added IEEE754 reference. IEEE754, and an IEEE754 reference.
o Added language about interoperability and Unicode characters, and o Added language about interoperability and Unicode characters, and
about string comparisons. To do this, turned the old "Encoding" about string comparisons. To do this, turned the old "Encoding"
section into a "Character Model" section, with three subsections: section into a "String and Character Issues" section, with three
The old "Encoding" material, and two new sections for "Unicode subsections: The old "Encoding" material, and two new sections for
Characters" and "String Comparison". "Unicode Characters" and "String Comparison".
o Made a real "Security Considerations" section, and lifted the text o Changed guidance in "Parsers" section to point out that
out of the existing "IANA Considerations" section. implementations may set limits on the range "and precision" of
numbers.
o Removed the language "Interoperability considerations: n/a" from o Removed the language "Interoperability considerations: n/a" from
the "IANA Considerations" section. the "IANA Considerations" section.
o Made a real "Security Considerations" section, and lifted the text
out of the existing "IANA Considerations" section.
o Applied erratum #3607 from RFC 4627 by removing the security
consideration that begins "A JSON text can be safely passed" and
the JavaScript code that went with that consideration.
o Added a note to the "Security Considerations" section pointing out
the risks of using the "eval()" function in JavaScript or any
other language in which JSON texts conform to that language's
syntax.
o Added "Contributors" section crediting Douglas Crockford. o Added "Contributors" section crediting Douglas Crockford.
o Changed "as sequences of digits" to "in the grammar below" in o Moved the ECMAScript reference from Normative to Informative,
"Numbers" section. updated it to reference ECMAScript 5.1, and added reference to
ECMA 404.
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 object or array.
JSON-text = object / array JSON-text = object / array
skipping to change at page 7, line 26 skipping to change at page 8, line 6
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
of numbers accepted. Since software which implements IEEE 754-2008 and precision of numbers accepted. Since software which implements
[IEEE754] is generally available and widely used, good IEEE 754-2008 [IEEE754] is generally available and widely used, good
interoperability can be achieved by implementations which expect no interoperability can be achieved by implementations which expect no
more precision or range than provided by an IEEE 754 binary64 (double more precision or range than provided by an IEEE 754 binary64 (double
precision) number, in the sense that implementations will approximate precision) number, in the sense that implementations will approximate
JSON numbers within the expected precision. A JSON number which is JSON numbers within the expected precision. A JSON number which is
outside those bounds, such as 1E400 or outside those bounds, such as 1E400 or
3.141592653589793238462643383279, may indicate potential 3.141592653589793238462643383279, may indicate potential
interoperability problems since it suggests that the software which interoperability problems since it suggests that the software which
created it it expected greater magnitude or precision than is widely created it it expected greater magnitude or precision than is widely
available. available.
Note that when such software is used, numbers which are integers, are Note that when such software is used, numbers which are integers and
in the range [-(2**53)+1, (2**53)-1], and are represented without are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
"frac" or "exp" parts (for example as 3 not 3.0), are interoperable sense that implementations will agree exactly on their numeric
in the sense that implementations will agree exactly on the numeric
values. values.
Numbers which represent zero without a sign, for example as 0 or 0.0
not -0 or -0.0, are interoperable in the sense that software
implementations will agree on the zero value. Signed zeros are
significant in some numerically-intensive applications, but
implementations which read JSON texts cannot be relied upon to
preserve that distinction.
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
skipping to change at page 9, line 5 skipping to change at page 9, line 25
%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. Character Model 8. String and Character Issues
8.1. Encoding and Detection 8.1. Encoding and Detection
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.
Since the first two characters of a JSON text will always be ASCII Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet 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 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. at the pattern of nulls in the first four octets.
skipping to change at page 10, line 13 skipping to change at page 10, line 35
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
nesting. An implementation may set limits on the range of numbers. nesting. An implementation may set limits on the range and precision
An implementation may set limits on the length and character contents of numbers. An implementation may set limits on the length and
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 MIME media type for JSON text is application/json.
Type name: application Type name: application
skipping to change at page 12, line 10 skipping to change at page 12, line 10
Change controller: Change controller:
Douglas Crockford Douglas Crockford
douglas@crockford.com douglas@crockford.com
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
use that language's "eval()" function to parse JSON texts. This
generally constitutes an unacceptable security risk, since the text
could contain executable code along with data declarations. The same
consideration applies in any other programming languages 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": {
skipping to change at page 13, line 31 skipping to change at page 13, line 31
"City": "SUNNYVALE", "City": "SUNNYVALE",
"State": "CA", "State": "CA",
"Zip": "94085", "Zip": "94085",
"Country": "US" "Country": "US"
} }
] ]
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 additions to and constructed by making a relatively small number of changes to that
subtractions from that document; thus the vast majority of the text document; thus the vast majority of the text here is his.
here is his.
15. Normative References 15. References
[ECMA] European Computer Manufacturers Association, "ECMAScript 15.1. Normative References
Language Specification 3rd Edition ", December 1999,
<http://www.ecma-international.org/publications/files/
ecma-st/ECMA-262.pdf>.
[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/>.
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005. Syntax Specifications: ABNF", RFC 4234, October 2005.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 4.0 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 4.0
", 2003, <http://www.unicode.org/versions/latest/>. ", 2003, <http://www.unicode.org/versions/latest/>.
15.2. Informative References
[ECMA-262]
European Computer Manufacturers Association, "ECMAScript
Language Specification 5.1 Edition ", June 2011, <http://
www.ecma-international.org/ecma-262/5.1/>.
[ECMA-404]
Ecma International, "The JSON Data Interchange Format ",
October 2013, <http://www.ecma-international.org/
publications/standards/Ecma-404.htm>.
Appendix A. Changes in -04 Appendix A. Changes in -04
o Reworded Section 8.2 to talk about strings that are represented in o Reworded Section 8.2 to talk about strings that are represented in
the JSON text, rather than the actual text itself. Also fine- the JSON text, rather than the actual text itself. Also fine-
tuned the "will agree on" clause in the interoperability tuned the "will agree on" clause in the interoperability
description. description.
o Changed "20008" to "2008". o Changed "20008" to "2008".
o Reworded numeric-interoperability language following on WG o Reworded numeric-interoperability language following on WG
discussion, notably referring to availability of software that discussion, notably referring to availability of software that
does IEEE754 and "approximate JSON numbers within the expected does IEEE754 and "approximate JSON numbers within the expected
precision". Also took out duplicate language about NaN and Inf. precision". Also took out duplicate language about NaN and Inf.
o Changed "as sequences of digits" to "in the grammar below" in o Changed "as sequences of digits" to "in the grammar below" in
"Numbers" section. "Numbers" section.
Appendix B. Changes in -05
o Removed the numbers-interop text about "frac" and "exp" parts.
o Added the obsoletes 4627 attribute.
o Moved the EcmaScript ref from normative to informative, and
redirected to point at 5.1.
o Changed numbers language to say that implementations can impose
limits on range *and precision*.
o Changed section title from "Character Model" to "String and
Character Issues".
o Added "Specifications of JSON" section, and included a reference
to ECMA-404.
o Removed the consensus-call link from the list of changes.
o Added a paragraph about not using eval() in JavaScript or other
languaegs where JSON syntax matches that language's syntax.
o Reorganized the list of changes so they're ordered like the spec,
and cleaned up language a bit.
Author's Address Author's Address
Tim Bray (editor) Tim Bray (editor)
Google, Inc. Google, Inc.
Email: tbray@textuality.com Email: tbray@textuality.com
 End of changes. 31 change blocks. 
63 lines changed or deleted 129 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/