idnits 2.17.00 (12 Aug 2021) /tmp/idnits58259/draft-ietf-json-rfc4627bis-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.) ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 06, 2013) is 3270 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) -- Looks like a reference, but probably isn't: '116' on line 335 -- Looks like a reference, but probably isn't: '943' on line 335 -- Looks like a reference, but probably isn't: '234' on line 335 -- Looks like a reference, but probably isn't: '38793' on line 335 == Unused Reference: 'RFC0020' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 384, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Working Group D. Crockford 3 Internet-Draft JSON.org 4 Intended status: Standards Track June 06, 2013 5 Expires: December 08, 2013 7 The JSON Data Interchange Format 8 draft-ietf-json-rfc4627bis-01 10 Abstract 12 JSON is a lightweight, text-based, language-independent data 13 interchange format. It was derived from the ECMAScript Programming 14 Language Standard. JSON defines a small set of formatting rules for 15 the portable representation of structured data. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 08, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 53 1.2. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 3 54 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Values . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.5. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 JSON is a text format for the serialization of structured data. It 70 was inspired by the object literals of JavaScript, as defined in the 71 ECMAScript Programming Language Standard, Fifth Edition[ECMA]. 73 JSON can represent four primitive types (strings, numbers, booleans, 74 and null) and two structured types (objects and arrays). 76 A string is a sequence of zero or more characters. 78 An object is an unordered collection of zero or more name/value 79 pairs, where a name is a string and a value is a string, number, 80 boolean, null, object, or array. 82 An array is an ordered sequence of zero or more values. 84 The terms "object" and "array" come from the conventions of 85 JavaScript. 87 JSON's design goals were for it to be minimal, portable, textual, and 88 a subset of JavaScript. JSON stands for JavaScript Object Notation. 90 1.1. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 The grammatical rules in this document are to be interpreted as 97 described in [RFC5234]. 99 1.2. Changes from RFC 4627 101 This section lists all changes between this document and the text in 102 RFC 4627. 104 o Applied errata #607 from RFC 4627 to correctly align the artwork 105 for the definition of "object". 107 2. JSON Grammar 109 A JSON text is a sequence of tokens. The set of tokens includes six 110 structural characters, strings, numbers, and three literal names. 112 A JSON text is a serialized object or array. 114 JSON-text = object / array 116 These are the six structural characters: 118 begin-array = ws %x5B ws ; [ left square bracket 120 begin-object = ws %x7B ws ; { left curly bracket 122 end-array = ws %x5D ws ; ] right square bracket 124 end-object = ws %x7D ws ; } right curly bracket 126 name-separator = ws %x3A ws ; : colon 128 value-separator = ws %x2C ws ; , comma 130 Insignificant whitespace is allowed before or after any of the six 131 structural characters. 133 ws = *( 134 %x20 / ; Space 135 %x09 / ; Horizontal tab 136 %x0A / ; Line feed or New line 137 %x0D ; Carriage return 138 ) 140 2.1. Values 142 A JSON value MUST be an object, array, number, or string, or one of 143 the following three literal names: 145 false null true 147 The literal names MUST be lowercase. No other literal names are 148 allowed. 150 value = false / null / true / object / array / number / string 152 false = %x66.61.6c.73.65 ; false 154 null = %x6e.75.6c.6c ; null 156 true = %x74.72.75.65 ; true 158 2.2. Objects 160 An object structure is represented as a pair of curly brackets 161 surrounding zero or more name/value pairs (or members). A name is a 162 string. A single colon comes after each name, separating the name 163 from the value. A single comma separates a value from a following 164 name. The names within an object SHOULD be unique. If a key is 165 duplicated, a parser MAY reject. If it does not reject, then it MUST 166 take only the last of the duplicated key pairs. 168 object = begin-object [ member *( value-separator member ) ] 169 end-object 171 member = string name-separator value 173 2.3. Arrays 175 An array structure is represented as square brackets surrounding zero 176 or more values (or elements). Elements are separated by commas. 178 array = begin-array [ value *( value-separator value ) ] end-array 180 2.4. Numbers 182 A number is represented in base 10 with no superfluous leading zeroes 183 or punctuation such as commas or spaces. It may have a preceding 184 minus sign. It may have a "."-prefixed fractional part. It may have 185 an exponent, prefixed by "e" or "E" and optionally "+" or "-". 187 Numeric values that cannot be represented as sequences of digits 188 (such as Infinity and NaN) are not permitted. 190 number = [ minus ] int [ frac ] [ exp ] 192 decimal-point = %x2E ; . 194 digit1-9 = %x31-39 ; 1-9 196 e = %x65 / %x45 ; e E 198 exp = e [ minus / plus ] 1*DIGIT 200 frac = decimal-point 1*DIGIT 202 int = zero / ( digit1-9 *DIGIT ) 204 minus = %x2D ; - 206 plus = %x2B ; + 208 zero = %x30 ; 0 210 2.5. Strings 212 The representation of strings is similar to conventions used in the C 213 family of programming languages. A string is a sequence of code 214 units wrapped with quotation marks. All characters may be placed 215 within the quotation marks except for the characters that must be 216 escaped: quotation mark, reverse solidus, and the control characters 217 (U+0000 through U+001F). 219 Any character may be escaped. If the character is in the Basic 220 Multilingual Plane (U+0000 through U+FFFF), then it may be 221 represented as a six-character sequence: a reverse solidus, followed 222 by the lowercase letter u, followed by four hexadecimal digits that 223 encode the character's Unicode code point. The hexadecimal letters A 224 though F can be upper or lowercase. So, for example, a string 225 containing only a single reverse solidus character may be represented 226 as "\u005C". 228 Alternatively, there are two-character sequence escape 229 representations of some popular characters. So, for example, a 230 string containing only a single reverse solidus character may be 231 represented more compactly as "\\". 233 string = quotation-mark *char quotation-mark 235 char = unescaped / 236 escape ( 237 %x22 / ; " quotation mark U+0022 238 %x5C / ; \ reverse solidus U+005C 239 %x2F / ; / solidus U+002F 240 %x62 / ; b backspace U+0008 241 %x66 / ; f form feed U+000C 242 %x6E / ; n line feed U+000A 243 %x72 / ; r carriage return U+000D 244 %x74 / ; t tab U+0009 245 %x75 4HEXDIG ) ; uXXXX U+XXXX 247 escape = %x5C ; \ 249 quotation-mark = %x22 ; " 251 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 253 The following four cases MUST all produce the same result: 255 "\u002F" 256 "\u002F" 257 "\/" 258 "/" 260 To escape an extended character that is not in the Basic Multilingual 261 Plane, the character is represented as a twelve-character sequence, 262 encoding the UTF-16 surrogate pair. So for example, a string 263 containing only the G clef character (U+1D11E) may be represented as 264 "\uD834\uDD1E". A generator SHOULD NOT emit unpaired surrogates. A 265 parser MAY reject JSON text containing unpaired surrogates. 267 3. Parsers 269 A JSON parser transforms a JSON text into another representation. A 270 JSON parser MUST accept all texts that conform to the JSON grammar. 271 A JSON parser MAY accept non-JSON forms or extensions. 273 An implementation may set limits on the size of texts that it 274 accepts. An implementation may set limits on the maximum depth of 275 nesting. An implementation may set limits on the range of numbers. 276 An implementation may set limits on the length and character contents 277 of strings. 279 4. Generators 281 A JSON generator produces JSON text. The resulting text MUST 282 strictly conform to the JSON grammar. 284 5. Security Considerations 286 With any data format, it is important to encode correctly. Care must 287 be taken when constructing JSON texts by concatenation. For example: 289 account = 4627; 290 comment = "\",\"account\":262"; // provided by attacker 291 json_text = "(\"account\":" + account + ",\"comment\":\"" + comment + "\"}"; 293 The result will be 295 {"account":4627,"comment":"","account":262} 297 which some parsers MAY see as being the same as 299 {"comment":"","account":262} 301 This confusion allows an attacker to modify the account property or 302 any other property. 304 It is much wiser to use JSON generators, which are available in many 305 forms for most programming languages, to do the encoding, avoiding 306 the confusion hazard. 308 JSON is so similar to some programming languages that the native 309 parsing ability of the language processors can be used to parse JSON 310 texts. This should be avoided because the native parser will accept 311 code which is not JSON. 313 For example, JavaScript's eval() function is able parse JSON text, 314 but is can also parse programs. If an attacker can inject code into 315 the JSON text (as we saw above), then it can compromise the system. 316 JSON parsers should always be used instead. 318 The web browser's script tag is an alias for the eval() function. It 319 should not be used to deliver JSON text to web browsers. 321 6. Examples 323 This is a JSON object: 325 { 326 "Image": { 327 "Width": 800, 328 "Height": 600, 329 "Title": "View from 15th Floor", 330 "Thumbnail": { 331 "Url": "http://www.example.com/image/481989943", 332 "Height": 125, 333 "Width": "100" 334 }, 335 "IDs": [116, 943, 234, 38793] 336 } 337 } 339 Its Image member is an object whose Thumbnail member is an object and 340 whose IDs member is an array of numbers. 342 This is a JSON array containing two objects: 344 [ 345 { 346 "precision": "zip", 347 "Latitude": 37.7668, 348 "Longitude": -122.3959, 349 "Address": "", 350 "City": "SAN FRANCISCO", 351 "State": "CA", 352 "Zip": "94107", 353 "Country": "US" 354 }, 355 { 356 "precision": "zip", 357 "Latitude": 37.371991, 358 "Longitude": -122.026020, 359 "Address": "", 360 "City": "SUNNYVALE", 361 "State": "CA", 362 "Zip": "94085", 363 "Country": "US" 364 } 366 ] 368 7. Normative References 370 [ECMA] European Computer Manufacturers Association, "ECMAScript 371 Language Specification Fifth Edition ", December 2009, 372 . 375 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 376 October 1969. 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 382 Specifications: ABNF", STD 68, RFC 5234, January 2008. 384 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.2 385 ", 2012, . 387 Author's Address 389 Douglas Crockford 390 JSON.org 392 Email: douglas@crockford.com