Internet DRAFT - draft-bray-i-json
draft-bray-i-json
Internet Engineering Task Force T. Bray, Ed.
Internet-Draft Google, Inc.
Intended status: Standards Track January 06, 2014
Expires: July 10, 2014
The I-JSON Message Format
draft-bray-i-json-01
Abstract
I-JSON is a restricted profile of JSON designed to maximize
interoperability and increase confidence that software can process it
successfully with predictable results.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bray Expires July 10, 2014 [Page 1]
Internet-Draft The I-JSON Message Format January 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. I-JSON Messages . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Encoding and Characters . . . . . . . . . . . . . . . . . 3
2.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Object constraints . . . . . . . . . . . . . . . . . . . 3
3. Software Behavior . . . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
RFC4627bis describes the JSON data interchange format, which is
widely used in Internet protocols. For historical reasons, that
specification allows the use of language idioms and text encoding
patterns which are likely to lead to interoperability problems and
software breakage, particularly when a program receiving JSON data
uses automated software to map it into native programming-language
structures or database records. RFC4627 describes practices which
may be used to avoid these interoperability problems.
This document specifies I-JSON, short for "Internet JSON". The unit
of definition is the "I-JSON message". I-JSON messages are also
"JSON texts" as defined in RFC4627bis but with certain extra
constraints which enforce the good interoperability practices
described in that specification.
1.1. Terminology
The terms "object", "member", "array", "number", "name", and "string"
in this document are to be interpreted as described in RFC4627bis.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Bray Expires July 10, 2014 [Page 2]
Internet-Draft The I-JSON Message Format January 2014
2. I-JSON Messages
An I-JSON message is a JSON object, as defined by RFC4626bis. This
allows protocol designers to add new data items to messages, should
that become necessary, without breaking existing deployments. In
other words, it makes a Must-Ignore policy possible.
When an I-JSON message is transmitted over the Internet, since it is
a JSON text as defined in RFC4627bis, it may be described using the
Internet Media Type "application/json". Specifications whose
messages are specified to be I-JSON messages SHOULD specify the use
of a media type of the form "application/XXX+i-json", where XXX is
specific to the specification.
2.1. Encoding and Characters
I-JSON messages MUST be encoded using UTF-8 [RFC3629].
Object member names, and string values in arrays and object members,
MUST NOT include code points which identify Surrogates or
Noncharacters.
This applies both to characters encoded directly in UTF-8 and to
those which are escaped; thus, "\uDEAD" is always illegal.
2.2. Numbers
Software which implements IEEE 754-2008 binary64 (double precision)
numbers [IEEE754] is generally available and widely used.
Implementations which generate I-JSON messages MUST NOT assume that
receiving implementations can process numeric values with greater
magnitude or precision than provided by those numbers. I-JSON
messages SHOULD NOT include numbers which express greater magnitude
or precision than an IEEE 754 double precision number provides, for
example 1E400 or 3.141592653589793238462643383279.
For applications such as cryptography, where much larger numbers are
reasonably required, it is RECOMMENDED to encode them in JSON string
values. This requires that the receiving program understand the
intended semantic of the value.
2.3. Object constraints
Objects in I-JSON messages MUST NOT have members with duplicate
names.
Bray Expires July 10, 2014 [Page 3]
Internet-Draft The I-JSON Message Format January 2014
Implementations which generate I-JSON messages MUST NOT assume that
the order of object members in those messages is available to
software which receives them.
3. Software Behavior
When software reads data which it expects to be an I-JSON message,
but the data violates one of the MUST constraints in the previous
section (for example, contains an object with a duplicate key, or a
UTF-8 encoding error), that software MUST NOT trust nor act on the
content of the message.
Designers of protocols which use I-JSON messages SHOULD provide a
way, in this case, for the receiver of the erroneous data to signal
the problem to the sender.
4. Acknowledgements
I-JSON is entirely dependent on the design of JSON, largely due to
Douglas Crockford. The specifics were strongly influenced by the
contributors to the design of RFC4627bis on the IETF JSON Working
Group.
5. Security Considerations
All the security considerations which apply to JSON (see RFC4627bis)
apply to I-JSON. There are no additional security considerations
specific to I-JSON.
6. Normative References
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008,
<http://grouper.ieee.org/groups/754/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
Bray Expires July 10, 2014 [Page 4]
Internet-Draft The I-JSON Message Format January 2014
Author's Address
Tim Bray (editor)
Google, Inc.
Email: tbray@textuality.com
URI: https://www.tbray.org/
Bray Expires July 10, 2014 [Page 5]
