< draft-ietf-json-rfc4627bis-08.txt   draft-ietf-json-rfc4627bis-09.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) December 04, 2013 Obsoletes: 4627 (if approved) December 10, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: June 07, 2014 Expires: June 13, 2014
The JSON Data Interchange Format The JSON Data Interchange Format
draft-ietf-json-rfc4627bis-08 draft-ietf-json-rfc4627bis-09
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 removes inconsistencies with other specifications of
specification errors and offers experience-based interoperability JSON, repairs specification errors, and offers experience-based
guidance. interoperability guidance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 07, 2014. This Internet-Draft will expire on June 13, 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 . . . . . . . . . . . . . . 3 1.3. Introduction to This Revision . . . . . . . . . . . . . . 4
2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 3 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 9
8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 8 8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9
8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9 8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9
9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 4627 . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 4627 . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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-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].
skipping to change at page 3, line 48 skipping to change at page 4, line 15
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.
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 apply 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 value. Note that certain previous A JSON text is a serialized value. Note that certain previous
specifications of JSON constrained a JSON text to be an object or an specifications of JSON constrained a JSON text to be an object or an
array. Implementations which generate only objects or arrays where a array. Implementations which generate only objects or arrays where a
JSON text is called for will be interoperable in the sense that all JSON text is called for will be interoperable in the sense that all
implementations will accept these as conforming JSON texts. implementations will accept these as conforming JSON texts.
JSON-text = ws value ws JSON-text = ws value ws
skipping to change at page 5, line 42 skipping to change at page 6, line 12
object; other implementations report all of the name/value pairs, object; other implementations report all of the name/value pairs,
including duplicates. including duplicates.
5. Arrays 5. Arrays
An array structure is represented as square brackets surrounding zero An array structure is represented as square brackets surrounding zero
or more values (or elements). Elements are separated by commas. or more values (or elements). Elements are separated by commas.
array = begin-array [ value *( value-separator value ) ] end-array array = begin-array [ value *( value-separator value ) ] end-array
There is no requirement that the values in an array be of the same
type.
6. Numbers 6. Numbers
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 contains an integer component that programming languages. A number contains an integer component that
may be prefixed with an optional minus sign, which may be followed by may be prefixed with an optional minus sign, which may be followed by
a fraction part and/or an exponent part. a fraction part and/or an exponent part.
Octal and hex forms are not allowed. Leading zeros are not allowed. Octal and hex forms are not allowed. Leading zeros are not 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.
skipping to change at page 8, line 26 skipping to change at page 9, line 4
%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. Character Encoding 8.1. Character Encoding
JSON text SHALL be encoded in Unicode. The default encoding is JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default
UTF-8, and JSON texts which are encoded in UTF-8 are interoperable in encoding is UTF-8, and JSON texts which are encoded in UTF-8 are
the sense that they will be read successfully by the maximum number interoperable in the sense that they will be read successfully by the
of implementations; there are many implementations which cannot maximum number of implementations; there are many implementations
successfully read texts in other encodings (such as UTF-16 and which cannot successfully read texts in other encodings (such as
UTF-32). UTF-16 and UTF-32).
Implementations have been observed to generate JSON texts prefixed Implementations MUST NOT add a byte order mark to the beginning of a
with a Byte Order Mark character. While this is not allowed by the JSON text. In the interests of interoperability, implementations
grammar in this specification, in the interests of interoperability which parse JSON texts MAY ignore the presence of a byte order mark
it is RECOMMENDED that implementations which parse JSON texts ignore rather than treating it as an error.
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 10, line 26 skipping to change at page 11, line 4
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>
Note: No "charset" parameter is defined for this registration.
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.
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 to the use of eval()-like functions in any consideration applies to the use of eval()-like functions in any
skipping to change at page 11, line 48 skipping to change at page 12, line 28
"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 Here are three small JSON texts containing only values:
"Hello world!" "Hello world!"
42 42
true 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
skipping to change at page 13, line 13 skipping to change at page 13, line 42
publications/standards/Ecma-404.htm>. publications/standards/Ecma-404.htm>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
Appendix A. Changes from RFC 4627 Appendix A. Changes from RFC 4627
This section lists changes between this document and the text in RFC This section lists changes between this document and the text in RFC
4627. 4627.
o Changed Working Group attribution to JSON Working Group.
o Changed title and abstract of document. o Changed title and abstract of document.
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 Added a "Specifications of JSON" section. o Added a "Specifications of JSON" section.
o Added an "Introduction to this Revision" section. o Added an "Introduction to this Revision" section.
o Changed the definition of "JSON text" so that it can be any JSON
value, removing the constraint that it be an object or array.
o Added language about duplicate object member names and o Added language about duplicate object member names and
interoperability. interoperability.
o Clarified the absence of a requirement that values in an array be
of the same JSON type.
o Applied erratum #607 from RFC 4627 to correctly align the artwork o Applied erratum #607 from RFC 4627 to correctly align the artwork
for the definition of "object". for the definition of "object".
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.
o Added language about number interoperability as a function of o Added language about number interoperability as a function of
IEEE754, and an 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 "String and Character Issues" section, with three section into a "String and Character Issues" section, with three
subsections: The old "Encoding" material, and two new sections for subsections: "Character Encoding", "Unicode Characters" and
"Unicode Characters" and "String Comparison". "String Comparison".
o Changed guidance in "Parsers" section to point out that o Changed guidance in "Parsers" section to point out that
implementations may set limits on the range "and precision" of implementations may set limits on the range "and precision" of
numbers. numbers.
o Updated and tidied the "IANA Considerations" section. o Updated and tidied the "IANA Considerations" section.
o Made a real "Security Considerations" section, and lifted the text o Made a real "Security Considerations" section, and lifted the text
out of the existing "IANA Considerations" section. out of the existing "IANA Considerations" section.
o Applied erratum #3607 from RFC 4627 by removing the security o Applied erratum #3607 from RFC 4627 by removing the security
consideration that begins "A JSON text can be safely passed" and consideration that begins "A JSON text can be safely passed" and
the JavaScript code that went with that consideration. the JavaScript code that went with that consideration.
o Added a note to the "Security Considerations" section pointing out o Added a note to the "Security Considerations" section pointing out
the risks of using the "eval()" function in JavaScript or any the risks of using the "eval()" function in JavaScript or any
other language in which JSON texts conform to that language's other language in which JSON texts conform to that language's
syntax. syntax.
o Added a note to IANA considerations clarifying the absence of a
"charset" parameter for the application/json media type.
o Changed "100" to 100 and added a boolean field, both in the first o Changed "100" to 100 and added a boolean field, both in the first
example. example.
o Added examples of JSON texts which simple values, neither objects
nor arrays.
o Added "Contributors" section crediting Douglas Crockford. o Added "Contributors" section crediting Douglas Crockford.
o Added a reference to RFC4627. o Added a reference to RFC4627.
o Moved the ECMAScript reference from Normative to Informative, o Moved the ECMAScript reference from Normative to Informative,
updated it to reference ECMAScript 5.1, and added reference to updated it to reference ECMAScript 5.1, and added reference to
ECMA 404. ECMA 404.
Author's Address Author's Address
 End of changes. 28 change blocks. 
41 lines changed or deleted 66 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/