idnits 2.17.1 draft-ietf-json-i-json-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2014) is 3649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE754' ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bray, Ed. 3 Internet-Draft Textuality Services 4 Intended status: Standards Track April 30, 2014 5 Expires: November 1, 2014 7 The I-JSON Message Format 8 draft-ietf-json-i-json-00 10 Abstract 12 I-JSON is a restricted profile of JSON designed to maximize 13 interoperability and increase confidence that software can process it 14 successfully with predictable results. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 1, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. I-JSON Messages . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Encoding and Characters . . . . . . . . . . . . . . . . . 3 55 2.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3. Object constraints . . . . . . . . . . . . . . . . . . . 3 57 3. Software Behavior . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 RFC7159 describes the JSON data interchange format, which is widely 66 used in Internet protocols. For historical reasons, that 67 specification allows the use of language idioms and text encoding 68 patterns which are likely to lead to interoperability problems and 69 software breakage, particularly when a program receiving JSON data 70 uses automated software to map it into native programming-language 71 structures or database records. RFC 7149 describes practices which 72 may be used to avoid these interoperability problems. 74 This document specifies I-JSON, short for "Internet JSON". The unit 75 of definition is the "I-JSON message". I-JSON messages are also 76 "JSON texts" as defined in RFC7159 but with certain extra constraints 77 which enforce the good interoperability practices described in that 78 specification. 80 1.1. Terminology 82 The terms "object", "member", "array", "number", "name", and "string" 83 in this document are to be interpreted as described in RFC 7159 84 [RFC7159]. 86 1.2. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. I-JSON Messages 94 An I-JSON message is a JSON object, as defined by RFC 7159. This 95 allows protocol designers to add new data items to messages, should 96 that become necessary, without breaking existing deployments. In 97 other words, it makes a Must-Ignore policy possible. 99 When an I-JSON message is transmitted over the Internet, since it is 100 a JSON text as defined in RFC 7159, it may be described using the 101 Internet Media Type "application/json". Specifications whose 102 messages are specified to be I-JSON messages SHOULD specify the use 103 of a media type of the form "application/XXX+i-json", where XXX is 104 specific to the specification. 106 2.1. Encoding and Characters 108 I-JSON messages MUST be encoded using UTF-8 [RFC3629]. 110 Object member names, and string values in arrays and object members, 111 MUST NOT include code points which identify Surrogates or 112 Noncharacters. 114 This applies both to characters encoded directly in UTF-8 and to 115 those which are escaped; thus, "\uDEAD" is always illegal. 117 2.2. Numbers 119 Software which implements IEEE 754-2008 binary64 (double precision) 120 numbers [IEEE754] is generally available and widely used. 121 Implementations which generate I-JSON messages MUST NOT assume that 122 receiving implementations can process numeric values with greater 123 magnitude or precision than provided by those numbers. I-JSON 124 messages SHOULD NOT include numbers which express greater magnitude 125 or precision than an IEEE 754 double precision number provides, for 126 example 1E400 or 3.141592653589793238462643383279. 128 For applications such as cryptography, where much larger numbers are 129 reasonably required, it is RECOMMENDED to encode them in JSON string 130 values. This requires that the receiving program understand the 131 intended semantic of the value. 133 2.3. Object constraints 135 Objects in I-JSON messages MUST NOT have members with duplicate 136 names. 138 Implementations which generate I-JSON messages MUST NOT assume that 139 the order of object members in those messages is available to 140 software which receives them. 142 3. Software Behavior 144 When software reads data which it expects to be an I-JSON message, 145 but the data violates one of the MUST constraints in the previous 146 section (for example, contains an object with a duplicate key, or a 147 UTF-8 encoding error), that software MUST NOT trust nor act on the 148 content of the message. 150 Designers of protocols which use I-JSON messages SHOULD provide a 151 way, in this case, for the receiver of the erroneous data to signal 152 the problem to the sender. 154 4. Acknowledgements 156 I-JSON is entirely dependent on the design of JSON, largely due to 157 Douglas Crockford. The specifics were strongly influenced by the 158 contributors to the design of RFC 7159 on the IETF JSON Working 159 Group. 161 5. Security Considerations 163 All the security considerations which apply to JSON (see RFC 7159) 164 apply to I-JSON. There are no additional security considerations 165 specific to I-JSON. 167 6. Normative References 169 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008, 170 . 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 176 10646", STD 63, RFC 3629, November 2003. 178 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 179 Interchange Format", RFC 7159, March 2014. 181 Author's Address 182 Tim Bray (editor) 183 Textuality Services 185 Email: tbray@textuality.com 186 URI: https://www.tbray.org/