draft-ietf-json-i-json-01.txt   draft-ietf-json-i-json-02.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 13, 2014 Intended status: Standards Track June 30, 2014
Expires: December 15, 2014 Expires: January 1, 2015
The I-JSON Message Format The I-JSON Message Format
draft-ietf-json-i-json-01 draft-ietf-json-i-json-02
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 December 15, 2014. This Internet-Draft will expire on January 1, 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 3, line 18 skipping to change at page 3, line 18
2.1. Encoding and Characters 2.1. Encoding and Characters
I-JSON messages MUST be encoded using UTF-8 [RFC3629]. I-JSON messages MUST be encoded using UTF-8 [RFC3629].
Object member names, and string values in arrays and object members, Object member names, and string values in arrays and object members,
MUST NOT include code points which identify Surrogates or MUST NOT include code points which identify Surrogates or
Noncharacters. Noncharacters.
This applies both to characters encoded directly in UTF-8 and to This applies both to characters encoded directly in UTF-8 and to
those which are escaped; thus, "\uDEAD" is always illegal because it those which are escaped; thus, "\uDEAD" is invalid because it is an
is an unpaired surrogate, while "\uD800\uDEAD" would be legal. unpaired surrogate, while "\uD800\uDEAD" would be legal.
2.2. Numbers 2.2. Numbers
Software which implements IEEE 754-2008 binary64 (double precision) Software which implements IEEE 754-2008 binary64 (double precision)
numbers [IEEE754] is generally available and widely used. numbers [IEEE754] is generally available and widely used.
Implementations which generate I-JSON messages MUST NOT assume that Implementations which generate I-JSON messages MUST NOT assume that
receiving implementations can process numeric values with greater receiving implementations can process numeric values with greater
magnitude or precision than provided by those numbers. I-JSON magnitude or precision than provided by those numbers. I-JSON
messages SHOULD NOT include numbers which express greater magnitude messages SHOULD NOT include numbers which express greater magnitude
or precision than an IEEE 754 double precision number provides, for or precision than an IEEE 754 double precision number provides, for
example 1E400 or 3.141592653589793238462643383279. example 1E400 or 3.141592653589793238462643383279.
In particular, an I-JSON sender MUST NOT expect a receiver to treat In particular, an I-JSON sender MUST NOT expect a receiver to treat
an integer whose absolute value is greater than 9007199254740991 an integer whose absolute value is greater than 9007199254740991
(i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact
value. value.
For applications such as cryptography, where exact interchange of For applications which require the exact interchange of numbers with
much larger numbers is required, it is RECOMMENDED to encode them in greater magnitude or precision (one example would be 64-bit
JSON string values. This requires that the receiving program integers), it is RECOMMENDED to encode them in JSON string values.
understand the intended semantic of the value. This requires that the receiving program understand the intended
semantic of the value.
2.3. Object constraints 2.3. Object constraints
Objects in I-JSON messages MUST NOT have members with duplicate Objects in I-JSON messages MUST NOT have members with duplicate
names. names. In this context, "duplicate" means that the names, after
processing any escaped characters, are identical sequences of Unicode
characters.
Implementations which generate I-JSON messages MUST NOT assume that Implementations which generate I-JSON messages MUST NOT assume that
the order of object members in those messages is available to the order of object members in those messages is available to
software which receives them. software which receives them.
3. Software Behavior 3. Software Behavior
When software reads data which it expects to be an I-JSON message, 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 but the data violates one of the MUST constraints in the previous
section (for example, contains an object with a duplicate key, or a section (for example, contains an object with a duplicate key, or a
skipping to change at page 5, line 8 skipping to change at page 5, line 8
to be overly restrictive and brittle. to be overly restrictive and brittle.
A good way to support the use of Must-Ignore in I-JSON protocol A good way to support the use of Must-Ignore in I-JSON protocol
designs is to require that top-level protocol elements must be JSON designs is to require that top-level protocol elements must be JSON
objects, and to specify that members whose names are unrecognized objects, and to specify that members whose names are unrecognized
MUST NOT produce behavior changes. MUST NOT produce behavior changes.
4.3. Time and Date Handling 4.3. Time and Date Handling
Protocols often contain data items which are designed to contain Protocols often contain data items which are designed to contain
timestamps or time durations. It is RECOMMENDED that in all such timestamps or time durations. It is RECOMMENDED that all such data
data items be expressed in in ISO 8601 format, as specified in items be expressed as string values in in ISO 8601 format, as
[RFC3339]. specified in [RFC3339], with the additional restriction that
uppercase rather than lowercase letters be used. It is also
RECOMMENDED that all data items containing time durations conform to
the "duration" production in Appendix A of RFC3339, with the same
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 base64url binary data, it is RECOMMENDED that this data be encoded in a string
RFC4648, section 5 [RFC4648]. value in base64url RFC4648, section 5 [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 23 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/