draft-ietf-json-i-json-02.txt   draft-ietf-json-i-json-03.txt 
Network Working Group T. Bray, Ed. Network Working Group T. Bray, Ed.
Internet-Draft Textuality Services Internet-Draft Textuality Services
Intended status: Standards Track June 30, 2014 Intended status: Standards Track August 5, 2014
Expires: January 1, 2015 Expires: February 6, 2015
The I-JSON Message Format The I-JSON Message Format
draft-ietf-json-i-json-02 draft-ietf-json-i-json-03
Abstract Abstract
I-JSON is a restricted profile of JSON designed to maximize I-JSON is a restricted profile of JSON designed to maximize
interoperability and increase confidence that software can process it interoperability and increase confidence that software can process it
successfully with predictable results. successfully with predictable results.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 1, 2015. This Internet-Draft will expire on February 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 2, line 27
4.2. Must-ignore Policy . . . . . . . . . . . . . . . . . . . 4 4.2. Must-ignore Policy . . . . . . . . . . . . . . . . . . . 4
4.3. Time and Date Handling . . . . . . . . . . . . . . . . . 5 4.3. Time and Date Handling . . . . . . . . . . . . . . . . . 5
4.4. Binary Data . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Binary Data . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
RFC7159 describes the JSON data interchange format, which is widely RFC 7159 describes the JSON data interchange format, which is widely
used in Internet protocols. For historical reasons, that used in Internet protocols. For historical reasons, that
specification allows the use of language idioms and text encoding specification allows the use of language idioms and text encoding
patterns which are likely to lead to interoperability problems and patterns which are likely to lead to interoperability problems and
software breakage, particularly when a program receiving JSON data software breakage, particularly when a program receiving JSON data
uses automated software to map it into native programming-language uses automated software to map it into native programming-language
structures or database records. RFC 7149 describes practices which structures or database records. RFC 7159 describes practices which
may be used to avoid these interoperability problems. may be used to avoid these interoperability problems.
This document specifies I-JSON, short for "Internet JSON". The unit This document specifies I-JSON, short for "Internet JSON". The unit
of definition is the "I-JSON message". I-JSON messages are also of definition is the "I-JSON message". I-JSON messages are also
"JSON texts" as defined in RFC7159 but with certain extra constraints "JSON texts" as defined in RFC 7159 but with certain extra
which enforce the good interoperability practices described in that constraints which enforce the good interoperability practices
specification. described in that specification.
1.1. Terminology 1.1. Terminology
The terms "object", "member", "array", "number", "name", and "string" The terms "object", "member", "array", "number", "name", and "string"
in this document are to be interpreted as described in RFC 7159 in this document are to be interpreted as described in RFC 7159
[RFC7159]. [RFC7159].
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 24 skipping to change at page 4, line 24
way, in this case, for the receiver of the erroneous data to signal way, in this case, for the receiver of the erroneous data to signal
the problem to the sender. the problem to the sender.
4. Protocol-design Recommendations 4. Protocol-design Recommendations
I-JSON is designed for use in Internet protocols. The following I-JSON is designed for use in Internet protocols. The following
recommendations apply to the use of I-JSON in such protocols. recommendations apply to the use of I-JSON in such protocols.
4.1. Top-level Constructs 4.1. Top-level Constructs
An I-JSON message can be any JSON object. However, there are An I-JSON message can be any JSON value. However, there are software
software implementations, coded to the older [RFC4627] specification, implementations, coded to the older [RFC4627] specification, which
which only accept JSON objects or JSON arrays at the top level of only accept JSON objects or JSON arrays at the top level of JSON
JSON texts. For maximum interoperability with such implementations, texts. For maximum interoperability with such implementations, it is
it is RECOMMENDED that protocol designers avoid the use of JSON texts RECOMMENDED that protocol designers avoid the use of top-level JSON
which are neither objects nor arrays. texts which are neither objects nor arrays.
4.2. Must-ignore Policy 4.2. Must-ignore Policy
It is frequently the case that changes to protocols are required It is frequently the case that changes to protocols are required
after they have been put in production. Protocols which allow the after they have been put in production. Protocols which allow the
introduction of new protocol elements in a way that does not disrupt introduction of new protocol elements in a way that does not disrupt
the operation of existing software have proven advantageous in the operation of existing software have proven advantageous in
practice. practice.
Such a policy is often referred to as "Must-Ignore" and is expressed Such a policy is often referred to as "Must-Ignore" and is expressed
skipping to change at page 5, line 20 skipping to change at page 5, line 20
specified in [RFC3339], with the additional restriction that specified in [RFC3339], with the additional restriction that
uppercase rather than lowercase letters be used. It is also uppercase rather than lowercase letters be used. It is also
RECOMMENDED that all data items containing time durations conform to RECOMMENDED that all data items containing time durations conform to
the "duration" production in Appendix A of RFC3339, with the same the "duration" production in Appendix A of RFC3339, with the same
additional restriction. additional restriction.
4.4. Binary Data 4.4. Binary Data
When it is required that an I-JSON protocol element contain arbitrary When it is required that an I-JSON protocol element contain arbitrary
binary data, it is RECOMMENDED that this data be encoded in a string binary data, it is RECOMMENDED that this data be encoded in a string
value in base64url RFC4648, section 5 [RFC4648]. value in base64url; see Section 5 of [RFC4648].
5. Acknowledgements 5. Acknowledgements
I-JSON is entirely dependent on the design of JSON, largely due to I-JSON is entirely dependent on the design of JSON, largely due to
Douglas Crockford. The specifics were strongly influenced by the Douglas Crockford. The specifics were strongly influenced by the
contributors to the design of RFC 7159 on the IETF JSON Working contributors to the design of RFC 7159 on the IETF JSON Working
Group. Group.
6. Security Considerations 6. Security Considerations
 End of changes. 8 change blocks. 
16 lines changed or deleted 16 lines changed or added

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