idnits 2.17.1 draft-bray-i-json-01.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 (January 06, 2014) is 3753 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) == Unused Reference: 'RFC4627' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'RFC6838' is defined on line 180, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE754' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Bray, Ed. 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track January 06, 2014 5 Expires: July 10, 2014 7 The I-JSON Message Format 8 draft-bray-i-json-01 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 July 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 RFC4627bis describes the JSON data interchange format, which is 66 widely 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. RFC4627 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 RFC4627bis but with certain extra 77 constraints which enforce the good interoperability practices 78 described in that 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 RFC4627bis. 85 1.2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. I-JSON Messages 93 An I-JSON message is a JSON object, as defined by RFC4626bis. This 94 allows protocol designers to add new data items to messages, should 95 that become necessary, without breaking existing deployments. In 96 other words, it makes a Must-Ignore policy possible. 98 When an I-JSON message is transmitted over the Internet, since it is 99 a JSON text as defined in RFC4627bis, it may be described using the 100 Internet Media Type "application/json". Specifications whose 101 messages are specified to be I-JSON messages SHOULD specify the use 102 of a media type of the form "application/XXX+i-json", where XXX is 103 specific to the specification. 105 2.1. Encoding and Characters 107 I-JSON messages MUST be encoded using UTF-8 [RFC3629]. 109 Object member names, and string values in arrays and object members, 110 MUST NOT include code points which identify Surrogates or 111 Noncharacters. 113 This applies both to characters encoded directly in UTF-8 and to 114 those which are escaped; thus, "\uDEAD" is always illegal. 116 2.2. Numbers 118 Software which implements IEEE 754-2008 binary64 (double precision) 119 numbers [IEEE754] is generally available and widely used. 120 Implementations which generate I-JSON messages MUST NOT assume that 121 receiving implementations can process numeric values with greater 122 magnitude or precision than provided by those numbers. I-JSON 123 messages SHOULD NOT include numbers which express greater magnitude 124 or precision than an IEEE 754 double precision number provides, for 125 example 1E400 or 3.141592653589793238462643383279. 127 For applications such as cryptography, where much larger numbers are 128 reasonably required, it is RECOMMENDED to encode them in JSON string 129 values. This requires that the receiving program understand the 130 intended semantic of the value. 132 2.3. Object constraints 134 Objects in I-JSON messages MUST NOT have members with duplicate 135 names. 137 Implementations which generate I-JSON messages MUST NOT assume that 138 the order of object members in those messages is available to 139 software which receives them. 141 3. Software Behavior 143 When software reads data which it expects to be an I-JSON message, 144 but the data violates one of the MUST constraints in the previous 145 section (for example, contains an object with a duplicate key, or a 146 UTF-8 encoding error), that software MUST NOT trust nor act on the 147 content of the message. 149 Designers of protocols which use I-JSON messages SHOULD provide a 150 way, in this case, for the receiver of the erroneous data to signal 151 the problem to the sender. 153 4. Acknowledgements 155 I-JSON is entirely dependent on the design of JSON, largely due to 156 Douglas Crockford. The specifics were strongly influenced by the 157 contributors to the design of RFC4627bis on the IETF JSON Working 158 Group. 160 5. Security Considerations 162 All the security considerations which apply to JSON (see RFC4627bis) 163 apply to I-JSON. There are no additional security considerations 164 specific to I-JSON. 166 6. Normative References 168 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 2008, 169 . 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, March 1997. 174 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 175 10646", STD 63, RFC 3629, November 2003. 177 [RFC4627] Crockford, D., "The application/json Media Type for 178 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 180 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 181 Specifications and Registration Procedures", BCP 13, RFC 182 6838, January 2013. 184 Author's Address 186 Tim Bray (editor) 187 Google, Inc. 189 Email: tbray@textuality.com 190 URI: https://www.tbray.org/