idnits 2.17.1 draft-ietf-json-rfc4627bis-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 05, 2013) is 3978 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 386 -- Looks like a reference, but probably isn't: '943' on line 386 -- Looks like a reference, but probably isn't: '234' on line 386 -- Looks like a reference, but probably isn't: '38793' on line 386 -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA' ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 05, 2013 5 Expires: December 07, 2013 7 The application/json Media Type for JavaScript Object Notation (JSON) 8 draft-ietf-json-rfc4627bis-02 10 Abstract 12 JavaScript Object Notation (JSON) is a lightweight, text-based, 13 language-independent data interchange format. It was derived from 14 the ECMAScript Programming Language Standard. JSON defines a small 15 set of formatting rules for the portable representation of structured 16 data. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 07, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 54 1.2. Changes from RFC 4627 . . . . . . . . . . . . . . . . . . 3 55 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Values . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.5. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 JavaScript Object Notation (JSON) is a text format for the 73 serialization of structured data. It is derived from the object 74 literals of JavaScript, as defined in the ECMAScript Programming 75 Language Standard, Third Edition [ECMA]. 77 JSON can represent four primitive types (strings, numbers, booleans, 78 and null) and two structured types (objects and arrays). 80 A string is a sequence of zero or more Unicode characters [UNICODE]. 82 An object is an unordered collection of zero or more name/value 83 pairs, where a name is a string and a value is a string, number, 84 boolean, null, object, or array. 86 An array is an ordered sequence of zero or more values. 88 The terms "object" and "array" come from the conventions of 89 JavaScript. 91 JSON's design goals were for it to be minimal, portable, textual, and 92 a subset of JavaScript. 94 1.1. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 The grammatical rules in this document are to be interpreted as 100 described in [RFC4234]. 102 1.2. Changes from RFC 4627 104 This section lists all changes between this document and the text in 105 RFC 4627. 107 o Applied errata #607 from RFC 4627 to correctly align the artwork 108 for the definition of "object". 110 2. JSON Grammar 112 A JSON text is a sequence of tokens. The set of tokens includes six 113 structural characters, strings, numbers, and three literal names. 115 A JSON text is a serialized object or array. 117 JSON-text = object / array 119 These are the six structural characters: 121 begin-array = ws %x5B ws ; [ left square bracket 123 begin-object = ws %x7B ws ; { left curly bracket 125 end-array = ws %x5D ws ; ] right square bracket 127 end-object = ws %x7D ws ; } right curly bracket 129 name-separator = ws %x3A ws ; : colon 131 value-separator = ws %x2C ws ; , comma 133 Insignificant whitespace is allowed before or after any of the six 134 structural characters. 136 ws = *( 137 %x20 / ; Space 138 %x09 / ; Horizontal tab 139 %x0A / ; Line feed or New line 140 %x0D ; Carriage return 142 ) 144 2.1. Values 146 A JSON value MUST be an object, array, number, or string, or one of 147 the following three literal names: 149 false null true 151 The literal names MUST be lowercase. No other literal names are 152 allowed. 154 value = false / null / true / object / array / number / string 156 false = %x66.61.6c.73.65 ; false 158 null = %x6e.75.6c.6c ; null 160 true = %x74.72.75.65 ; true 162 2.2. Objects 164 An object structure is represented as a pair of curly brackets 165 surrounding zero or more name/value pairs (or members). A name is a 166 string. A single colon comes after each name, separating the name 167 from the value. A single comma separates a value from a following 168 name. The names within an object SHOULD be unique. 170 object = begin-object [ member *( value-separator member ) ] 171 end-object 173 member = string name-separator value 175 2.3. Arrays 177 An array structure is represented as square brackets surrounding zero 178 or more values (or elements). Elements are separated by commas. 180 array = begin-array [ value *( value-separator value ) ] end-array 182 2.4. Numbers 183 The representation of numbers is similar to that used in most 184 programming languages. A number contains an integer component that 185 may be prefixed with an optional minus sign, which may be followed by 186 a fraction part and/or an exponent part. 188 Octal and hex forms are not allowed. Leading zeros are not allowed. 190 A fraction part is a decimal point followed by one or more digits. 192 An exponent part begins with the letter E in upper or lowercase, 193 which may be followed by a plus or minus sign. The E and optional 194 sign are followed by one or more digits. 196 Numeric values that cannot be represented as sequences of digits 197 (such as Infinity and NaN) are not permitted. 199 number = [ minus ] int [ frac ] [ exp ] 201 decimal-point = %x2E ; . 203 digit1-9 = %x31-39 ; 1-9 205 e = %x65 / %x45 ; e E 207 exp = e [ minus / plus ] 1*DIGIT 209 frac = decimal-point 1*DIGIT 211 int = zero / ( digit1-9 *DIGIT ) 213 minus = %x2D ; - 215 plus = %x2B ; + 217 zero = %x30 ; 0 219 2.5. Strings 221 The representation of strings is similar to conventions used in the C 222 family of programming languages. A string begins and ends with 223 quotation marks. All Unicode characters may be placed within the 224 quotation marks except for the characters that must be escaped: 225 quotation mark, reverse solidus, and the control characters (U+0000 226 through U+001F). 228 Any character may be escaped. If the character is in the Basic 229 Multilingual Plane (U+0000 through U+FFFF), then it may be 230 represented as a six-character sequence: a reverse solidus, followed 231 by the lowercase letter u, followed by four hexadecimal digits that 232 encode the character's code point. The hexadecimal letters A though 233 F can be upper or lowercase. So, for example, a string containing 234 only a single reverse solidus character may be represented as 235 "\u005C". 237 Alternatively, there are two-character sequence escape 238 representations of some popular characters. So, for example, a 239 string containing only a single reverse solidus character may be 240 represented more compactly as "\\". 242 To escape an extended character that is not in the Basic Multilingual 243 Plane, the character is represented as a twelve-character sequence, 244 encoding the UTF-16 surrogate pair. So, for example, a string 245 containing only the G clef character (U+1D11E) may be represented as 246 "\uD834\uDD1E". 248 string = quotation-mark *char quotation-mark 250 char = unescaped / 251 escape ( 252 %x22 / ; " quotation mark U+0022 253 %x5C / ; \ reverse solidus U+005C 254 %x2F / ; / solidus U+002F 255 %x62 / ; b backspace U+0008 256 %x66 / ; f form feed U+000C 257 %x6E / ; n line feed U+000A 258 %x72 / ; r carriage return U+000D 259 %x74 / ; t tab U+0009 260 %x75 4HEXDIG ) ; uXXXX U+XXXX 262 escape = %x5C ; \ 264 quotation-mark = %x22 ; " 266 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 268 3. Encoding 270 JSON text SHALL be encoded in Unicode. The default encoding is 271 UTF-8. 273 Since the first two characters of a JSON text will always be ASCII 274 characters [RFC0020], it is possible to determine whether an octet 275 stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking 276 at the pattern of nulls in the first four octets. 278 00 00 00 xx UTF-32BE 279 00 xx 00 xx UTF-16BE 280 xx 00 00 00 UTF-32LE 281 xx 00 xx 00 UTF-16LE 282 xx xx xx xx UTF-8 284 4. Parsers 286 A JSON parser transforms a JSON text into another representation. A 287 JSON parser MUST accept all texts that conform to the JSON grammar. 288 A JSON parser MAY accept non-JSON forms or extensions. 290 An implementation may set limits on the size of texts that it 291 accepts. An implementation may set limits on the maximum depth of 292 nesting. An implementation may set limits on the range of numbers. 293 An implementation may set limits on the length and character contents 294 of strings. 296 5. Generators 298 A JSON generator produces JSON text. The resulting text MUST 299 strictly conform to the JSON grammar. 301 6. IANA Considerations 303 The MIME media type for JSON text is application/json. 305 Type name: application 307 Subtype name: json 309 Required parameters: n/a 311 Optional parameters: n/a 313 Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32 315 JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON 316 is written in UTF-8, JSON is 8bit compatible. When JSON is 317 written in UTF-16 or UTF-32, the binary content-transfer-encoding 318 must be used. 320 Security considerations: 322 Generally there are security issues with scripting languages. JSON 323 is a subset of JavaScript, but it is a safe subset that excludes 324 assignment and invocation. 326 A JSON text can be safely passed into JavaScript's eval() function 327 (which compiles and executes a string) if all the characters not 328 enclosed in strings are in the set of characters that form JSON 329 tokens. This can be quickly determined in JavaScript with two 330 regular expressions and calls to the test and replace methods. 332 var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( 333 text.replace(/"(\\.|[^"\\])*"/g, ''))) && 334 eval('(' + text + ')'); 336 Interoperability considerations: n/a 338 Published specification: RFC 4627 340 Applications that use this media type: 342 JSON has been used to exchange data between applications written 343 in all of these programming languages: ActionScript, C, C#, 344 ColdFusion, Common Lisp, E, Erlang, Java, JavaScript, Lua, 345 Objective CAML, Perl, PHP, Python, Rebol, Ruby, and Scheme. 347 Additional information: 349 Magic number(s): n/a 350 File extension(s): .json 351 Macintosh file type code(s): TEXT 353 Person & email address to contact for further information: 354 Douglas Crockford 355 douglas@crockford.com 357 Intended usage: COMMON 359 Restrictions on usage: none 361 Author: 362 Douglas Crockford 363 douglas@crockford.com 365 Change controller: 366 Douglas Crockford 367 douglas@crockford.com 369 7. Security Considerations 370 See Security Considerations in Section 6. 372 8. Examples 374 This is a JSON object: 376 { 377 "Image": { 378 "Width": 800, 379 "Height": 600, 380 "Title": "View from 15th Floor", 381 "Thumbnail": { 382 "Url": "http://www.example.com/image/481989943", 383 "Height": 125, 384 "Width": "100" 385 }, 386 "IDs": [116, 943, 234, 38793] 387 } 388 } 390 Its Image member is an object whose Thumbnail member is an object and 391 whose IDs member is an array of numbers. 393 This is a JSON array containing two objects: 395 [ 396 { 397 "precision": "zip", 398 "Latitude": 37.7668, 399 "Longitude": -122.3959, 400 "Address": "", 401 "City": "SAN FRANCISCO", 402 "State": "CA", 403 "Zip": "94107", 404 "Country": "US" 405 }, 406 { 407 "precision": "zip", 408 "Latitude": 37.371991, 409 "Longitude": -122.026020, 410 "Address": "", 411 "City": "SUNNYVALE", 412 "State": "CA", 413 "Zip": "94085", 414 "Country": "US" 415 } 416 ] 418 9. Normative References 420 [ECMA] European Computer Manufacturers Association, "ECMAScript 421 Language Specification 3rd Edition ", December 1999, 422 . 425 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 426 October 1969. 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 432 Specifications: ABNF", RFC 4234, October 2005. 434 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 4.0 435 ", 2003, . 437 Author's Address 439 Douglas Crockford 440 JSON.org 442 Email: douglas@crockford.com