draft-ietf-json-i-json-04.txt   draft-ietf-json-i-json-05.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 November 26, 2014 Intended status: Standards Track December 18, 2014
Expires: May 30, 2015 Expires: June 21, 2015
The I-JSON Message Format The I-JSON Message Format
draft-ietf-json-i-json-04 draft-ietf-json-i-json-05
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 May 30, 2015. This Internet-Draft will expire on June 21, 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 25 skipping to change at page 3, line 25
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 invalid because it is an those which are escaped; thus, "\uDEAD" is invalid because it 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 cannot 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 cannot expect a receiver to treat an In particular, an I-JSON sender cannot expect a receiver to treat an
integer whose absolute value is greater than 9007199254740991 (i.e., integer whose absolute value is greater than 9007199254740991 (i.e.,
that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
processing any escaped characters, are identical sequences of Unicode processing any escaped characters, are identical sequences of Unicode
characters. characters.
The order of object members in an I-JSON message does not change the The order of object members in an I-JSON message does not change the
meaning of an I-JSON message. A receiving implementation MAY treat meaning of an I-JSON message. A receiving implementation MAY treat
two I-JSON messages as equivalent if they differ only in the order of two I-JSON messages as equivalent if they differ only in the order of
the object members. the object members.
3. Software Behavior 3. Software Behavior
When software reads data which it expects to be an I-JSON message, A major advantage of using I-JSON is that receivers can avoid
but the data violates one of the MUST constraints in the previous ambiguous semantics in the JSON messages it receives. This allows
section (for example, contains an object with a duplicate key, or a receivers to reject or otherwise disregard messages which do not
UTF-8 encoding error), that software MUST NOT trust nor act on the conform to the requirements in this document for I-JSON messages.
content of the message. Protocols that use I-JSON message can be written so that receiving
implementation are required to reject (or, as in the case of security
protocols, not trust) messages that do not satisfy the constraints of
I-JSON.
Designers of protocols which use I-JSON messages SHOULD provide a Designers of protocols which use I-JSON messages SHOULD provide a
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.
 End of changes. 5 change blocks. 
10 lines changed or deleted 13 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/