< draft-ietf-json-rfc4627bis-03.txt   draft-ietf-json-rfc4627bis-04.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 18, 2013 Intended status: Standards Track September 26, 2013
Expires: March 22, 2014 Expires: March 30, 2014
The JSON Data Interchange Format The JSON Data Interchange Format
draft-ietf-json-rfc4627bis-03 draft-ietf-json-rfc4627bis-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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 22, 2014. This Internet-Draft will expire on March 30, 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 17 skipping to change at page 2, line 17
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. Introduction to This Revision . . . . . . . . . . . . . . 3
1.3. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 3 1.3. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 3
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. Character Model . . . . . . . . . . . . . . . . . . . . . . . 8 8. Character Model . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Encoding and Detection . . . . . . . . . . . . . . . . . 8 8.1. Encoding and Detection . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Normative References . . . . . . . . . . . . . . . . . . . . 12 15. Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Changes in -04 . . . . . . . . . . . . . . . . . . . 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
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].
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).
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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 Tim Bray as editor. 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 Added language about intereoperability as a function of number o Added language about number interoperability as a function of
ranges and IEEE754. Also added IEEE754 reference. IEEE754. Also added 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 "Character Model" section, with three subsections:
The old "Encoding" material, and two new sections for "Unicode The old "Encoding" material, and two new sections for "Unicode
Characters" and "String Comparison". Characters" and "String Comparison".
o Made a real XML-level "Security Considerations" section, and o Made a real "Security Considerations" section, and lifted the text
lifted the text out of the existing "IANA Considerations" section. out of the existing "IANA Considerations" section.
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 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
"Numbers" section.
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
These are the six structural characters: These are the six structural characters:
skipping to change at page 6, line 29 skipping to change at page 6, line 32
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.
An exponent part begins with the letter E in upper or lowercase, An exponent part begins with the letter E in upper 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 as sequences of digits Numeric values that cannot be represented in the grammar below (such
(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 ; .
digit1-9 = %x31-39 ; 1-9 digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT exp = e [ minus / plus ] 1*DIGIT
skipping to change at page 7, line 6 skipping to change at page 7, line 26
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. While absolute interoperability cannot be of numbers accepted. Since software which implements IEEE 754-2008
guaranteed, wide interoperability can be achieved by limiting numbers [IEEE754] is generally available and widely used, good
in JSON texts to those within the precision and magnitude expressible interoperability can be achieved by implementations which expect no
in an IEEE 754:20008 binary64 (double precision) number [IEEE754]. more precision or range than provided by an IEEE 754 binary64 (double
Numeric values that cannot be represented in the grammar above (such precision) number, in the sense that implementations will approximate
as Infinity and NaN) are not permitted. Attempting to represent JSON numbers within the expected precision. A JSON number which is
numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 outside those bounds, such as 1E400 or
number, such as 1E400, 9007199254740993, or 3.141592653589793238462643383279, may indicate potential
3.141592653589793238462643383279, may cause interoperability interoperability problems since it suggests that the software which
problems. created it it expected greater magnitude or precision than is widely
available.
7. Strings Note that when such software is used, numbers which are integers, are
in the range [-(2**53)+1, (2**53)-1], and are represented without
"frac" or "exp" parts (for example as 3 not 3.0), are interoperable
in the sense that implementations will agree exactly on the numeric
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
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 8, line 45 skipping to change at page 9, line 25
at the pattern of nulls in the first four octets. at the pattern of nulls in the first four octets.
00 00 00 xx UTF-32BE 00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE 00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8 xx xx xx xx UTF-8
8.2. Unicode Characters 8.2. Unicode Characters
A JSON text which is composed entirely of Unicode characters When all the strings represented in a JSON text are composed entirely
[UNICODE] (however encoded) is interoperable in the sense that all of Unicode characters [UNICODE] (however escaped), then that JSON
software implementations which parse it will agree on the contents of text is interoperable in the sense that all software implementations
names and values of object members. However, the ABNF in this which parse it will agree on the contents of names and of string
specification allows member names and string values to contain bit values in objects and arrays.
sequences which cannot encode Unicode characters, for example
"\uDEAD" (a single unpaired UTF-16 surrogate). Instances of this However, the ABNF in this specification allows member names and
have been observed, for example when a library truncates a UTF-16 string values to contain bit sequences which cannot encode Unicode
string without checking whether the truncation split a surrogate characters, for example "\uDEAD" (a single unpaired UTF-16
pair. The behavior of software which receives JSON texts containing surrogate). Instances of this have been observed, for example when a
such values is unpredictable; for example, implementations might library truncates a UTF-16 string without checking whether the
return different values for the length of a string value, or even truncation split a surrogate pair. The behavior of software which
suffer a fatal runtime exception. receives JSON texts containing such values is unpredictable; for
example, implementations might return different values for the length
of a string value, or even suffer fatal runtime exceptions.
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
skipping to change at page 13, line 11 skipping to change at page 14, line 11
[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/>.
Appendix A. Changes in -04
o Reworded Section 8.2 to talk about strings that are represented in
the JSON text, rather than the actual text itself. Also fine-
tuned the "will agree on" clause in the interoperability
description.
o Changed "20008" to "2008".
o Reworded numeric-interoperability language following on WG
discussion, notably referring to availability of software that
does IEEE754 and "approximate JSON numbers within the expected
precision". Also took out duplicate language about NaN and Inf.
o Changed "as sequences of digits" to "in the grammar below" in
"Numbers" section.
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. 15 change blocks. 
46 lines changed or deleted 82 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/