idnits 2.17.1 draft-ietf-jsonbis-rfc7159bis-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 draft header indicates that this document obsoletes RFC4627, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC7158, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC7159, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2015) is 3113 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) == Missing Reference: 'RFC7159' is mentioned on line 435, but not defined ** Obsolete undefined reference: RFC 7159 (Obsoleted by RFC 8259) -- Looks like a reference, but probably isn't: '116' on line 497 -- Looks like a reference, but probably isn't: '943' on line 497 -- Looks like a reference, but probably isn't: '234' on line 497 -- Looks like a reference, but probably isn't: '38793' on line 497 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE754' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 4627 (ref. 'Err3607') (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 7159 (ref. 'Err3915') (Obsoleted by RFC 8259) -- Duplicate reference: RFC7159, mentioned in 'Err4264', was also mentioned in 'Err3915'. -- Obsolete informational reference (is this intentional?): RFC 7159 (ref. 'Err4264') (Obsoleted by RFC 8259) -- Duplicate reference: RFC7159, mentioned in 'Err4336', was also mentioned in 'Err4264'. -- Obsolete informational reference (is this intentional?): RFC 7159 (ref. 'Err4336') (Obsoleted by RFC 8259) -- Duplicate reference: RFC4627, mentioned in 'Err607', was also mentioned in 'Err3607'. -- Obsolete informational reference (is this intentional?): RFC 4627 (ref. 'Err607') (Obsoleted by RFC 7158, RFC 7159) -- Duplicate reference: RFC4627, mentioned in 'RFC4627', was also mentioned in 'Err607'. -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JSON Working Group T. Bray, Ed. 3 Internet-Draft Textuality 4 Obsoletes: 4627, 7158, 7159 (if approved) October 18, 2015 5 Intended status: Standards Track 6 Expires: April 20, 2016 8 The JavaScript Object Notation (JSON) Data Interchange Format 9 draft-ietf-jsonbis-rfc7159bis-00 11 Abstract 13 JavaScript Object Notation (JSON) is a lightweight, text-based, 14 language-independent data interchange format. It was derived from 15 the ECMAScript Programming Language Standard. JSON defines a small 16 set of formatting rules for the portable representation of structured 17 data. 19 This document removes inconsistencies with other specifications of 20 JSON, repairs specification errors, and offers experience-based 21 interoperability guidance. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 20, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 71 1.2. Specifications of JSON . . . . . . . . . . . . . . . . . 3 72 1.3. Introduction to This Revision . . . . . . . . . . . . . . 4 73 2. JSON Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8. String and Character Issues . . . . . . . . . . . . . . . . . 8 80 8.1. Character Encoding . . . . . . . . . . . . . . . . . . . 8 81 8.2. Unicode Characters . . . . . . . . . . . . . . . . . . . 9 82 8.3. String Comparison . . . . . . . . . . . . . . . . . . . . 9 83 9. Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 10. Generators . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 15.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Changes from RFC 4627 . . . . . . . . . . . . . . . 14 94 1. Introduction 96 JavaScript Object Notation (JSON) is a text format for the 97 serialization of structured data. It is derived from the object 98 literals of JavaScript, as defined in the ECMAScript Programming 99 Language Standard, Third Edition [ECMA-262]. 101 JSON can represent four primitive types (strings, numbers, booleans, 102 and null) and two structured types (objects and arrays). 104 A string is a sequence of zero or more Unicode characters [UNICODE]. 105 Note that this citation references the latest version of Unicode 106 rather than a specific release. It is not expected that future 107 changes in the UNICODE specification will impact the syntax of JSON. 109 An object is an unordered collection of zero or more name/value 110 pairs, where a name is a string and a value is a string, number, 111 boolean, null, object, or array. 113 An array is an ordered sequence of zero or more values. 115 The terms "object" and "array" come from the conventions of 116 JavaScript. 118 JSON's design goals were for it to be minimal, portable, textual, and 119 a subset of JavaScript. 121 1.1. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 The grammatical rules in this document are to be interpreted as 128 described in [RFC5234]. 130 1.2. Specifications of JSON 132 This document updates [RFC4627], which describes JSON and registers 133 the media type "application/json". 135 A description of JSON in ECMAScript terms appears in Version 5.1 of 136 the ECMAScript specification [ECMA-262], Section 15.12. JSON is also 137 described in [ECMA-404]. 139 All of the specifications of JSON syntax agree on the syntactic 140 elements of the language. 142 1.3. Introduction to This Revision 144 In the years since the publication of RFC 4627, JSON has found very 145 wide use. This experience has revealed certain patterns, which, 146 while allowed by its specifications, have caused interoperability 147 problems. 149 Also, a small number of errata have been reported to RFC4627 (see RFC 150 Errata IDs 607 [Err607] and 3607 [Err3607]) and to RFC7159 (see RFC 151 Errata IDs [Err3915], [Err4264], and [Err4336]). 153 This document's goal is to apply the errata, remove inconsistencies 154 with other specifications of JSON, and highlight practices that can 155 lead to interoperability problems. 157 2. JSON Grammar 159 A JSON text is a sequence of tokens. The set of tokens includes six 160 structural characters, strings, numbers, and three literal names. 162 A JSON text is a serialized value. Note that certain previous 163 specifications of JSON constrained a JSON text to be an object or an 164 array. Implementations that generate only objects or arrays where a 165 JSON text is called for will be interoperable in the sense that all 166 implementations will accept these as conforming JSON texts. 168 JSON-text = ws value ws 170 These are the six structural characters: 172 begin-array = ws %x5B ws ; [ left square bracket 174 begin-object = ws %x7B ws ; { left curly bracket 176 end-array = ws %x5D ws ; ] right square bracket 178 end-object = ws %x7D ws ; } right curly bracket 180 name-separator = ws %x3A ws ; : colon 182 value-separator = ws %x2C ws ; , comma 184 Insignificant whitespace is allowed before or after any of the six 185 structural characters. 187 ws = *( 188 %x20 / ; Space 189 %x09 / ; Horizontal tab 190 %x0A / ; Line feed or New line 191 %x0D ) ; Carriage return 193 3. Values 195 A JSON value MUST be an object, array, number, or string, or one of 196 the following three literal names: 198 false null true 200 The literal names MUST be lowercase. No other literal names are 201 allowed. 203 value = false / null / true / object / array / number / string 205 false = %x66.61.6c.73.65 ; false 207 null = %x6e.75.6c.6c ; null 209 true = %x74.72.75.65 ; true 211 4. Objects 213 An object structure is represented as a pair of curly brackets 214 surrounding zero or more name/value pairs (or members). A name is a 215 string. A single colon comes after each name, separating the name 216 from the value. A single comma separates a value from a following 217 name. The names within an object SHOULD be unique. 219 object = begin-object [ member *( value-separator member ) ] 220 end-object 222 member = string name-separator value 224 An object whose names are all unique is interoperable in the sense 225 that all software implementations receiving that object will agree on 226 the name-value mappings. When the names within an object are not 227 unique, the behavior of software that receives such an object is 228 unpredictable. Many implementations report the last name/value pair 229 only. Other implementations report an error or fail to parse the 230 object, and some implementations report all of the name/value pairs, 231 including duplicates. 233 JSON parsing libraries have been observed to differ as to whether or 234 not they make the ordering of object members visible to calling 235 software. Implementations whose behavior does not depend on member 236 ordering will be interoperable in the sense that they will not be 237 affected by these differences. 239 5. Arrays 241 An array structure is represented as square brackets surrounding zero 242 or more values (or elements). Elements are separated by commas. 244 array = begin-array [ value *( value-separator value ) ] end-array 246 There is no requirement that the values in an array be of the same 247 type. 249 6. Numbers 251 The representation of numbers is similar to that used in most 252 programming languages. A number is represented in base 10 using 253 decimal digits. It contains an integer component that may be 254 prefixed with an optional minus sign, which may be followed by a 255 fraction part and/or an exponent part. Leading zeros are not 256 allowed. 258 A fraction part is a decimal point followed by one or more digits. 260 An exponent part begins with the letter E in upper or lower case, 261 which may be followed by a plus or minus sign. The E and optional 262 sign are followed by one or more digits. 264 Numeric values that cannot be represented in the grammar below (such 265 as Infinity and NaN) are not permitted. 267 number = [ minus ] int [ frac ] [ exp ] 269 decimal-point = %x2E ; . 271 digit1-9 = %x31-39 ; 1-9 273 e = %x65 / %x45 ; e E 275 exp = e [ minus / plus ] 1*DIGIT 277 frac = decimal-point 1*DIGIT 279 int = zero / ( digit1-9 *DIGIT ) 281 minus = %x2D ; - 283 plus = %x2B ; + 285 zero = %x30 ; 0 287 This specification allows implementations to set limits on the range 288 and precision of numbers accepted. Since software that implements 289 IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is 290 generally available and widely used, good interoperability can be 291 achieved by implementations that expect no more precision or range 292 than these provide, in the sense that implementations will 293 approximate JSON numbers within the expected precision. A JSON 294 number such as 1E400 or 3.141592653589793238462643383279 may indicate 295 potential interoperability problems, since it suggests that the 296 software that created it expects receiving software to have greater 297 capabilities for numeric magnitude and precision than is widely 298 available. 300 Note that when such software is used, numbers that are integers and 301 are in the range [-(2**53)+1, (2**53)-1] are interoperable in the 302 sense that implementations will agree exactly on their numeric 303 values. 305 7. Strings 307 The representation of strings is similar to conventions used in the C 308 family of programming languages. A string begins and ends with 309 quotation marks. All Unicode characters may be placed within the 310 quotation marks, except for the characters that must be escaped: 311 quotation mark, reverse solidus, and the control characters (U+0000 312 through U+001F). 314 Any character may be escaped. If the character is in the Basic 315 Multilingual Plane (U+0000 through U+FFFF), then it may be 316 represented as a six-character sequence: a reverse solidus, followed 317 by the lowercase letter u, followed by four hexadecimal digits that 318 encode the character's code point. The hexadecimal letters A though 319 F can be upper or lower case. So, for example, a string containing 320 only a single reverse solidus character may be represented as 321 "\u005C". 323 Alternatively, there are two-character sequence escape 324 representations of some popular characters. So, for example, a 325 string containing only a single reverse solidus character may be 326 represented more compactly as "\\". 328 To escape an extended character that is not in the Basic Multilingual 329 Plane, the character is represented as a 12-character sequence, 330 encoding the UTF-16 surrogate pair. So, for example, a string 331 containing only the G clef character (U+1D11E) may be represented as 332 "\uD834\uDD1E". 334 string = quotation-mark *char quotation-mark 336 char = unescaped / 337 escape ( 338 %x22 / ; " quotation mark U+0022 339 %x5C / ; \ reverse solidus U+005C 340 %x2F / ; / solidus U+002F 341 %x62 / ; b backspace U+0008 342 %x66 / ; f form feed U+000C 343 %x6E / ; n line feed U+000A 344 %x72 / ; r carriage return U+000D 345 %x74 / ; t tab U+0009 346 %x75 4HEXDIG ) ; uXXXX U+XXXX 348 escape = %x5C ; \ 350 quotation-mark = %x22 ; " 352 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 354 8. String and Character Issues 356 8.1. Character Encoding 358 JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default 359 encoding is UTF-8, and JSON texts that are encoded in UTF-8 are 360 interoperable in the sense that they will be read successfully by the 361 maximum number of implementations; there are many implementations 362 that cannot successfully read texts in other encodings (such as 363 UTF-16 and UTF-32). 365 Implementations MUST NOT add a byte order mark to the beginning of a 366 JSON text. In the interests of interoperability, implementations 367 that parse JSON texts MAY ignore the presence of a byte order mark 368 rather than treating it as an error. 370 8.2. Unicode Characters 372 When all the strings represented in a JSON text are composed entirely 373 of Unicode characters [UNICODE] (however escaped), then that JSON 374 text is interoperable in the sense that all software implementations 375 that parse it will agree on the contents of names and of string 376 values in objects and arrays. 378 However, the ABNF in this specification allows member names and 379 string values to contain bit sequences that cannot encode Unicode 380 characters; for example, "\uDEAD" (a single unpaired UTF-16 381 surrogate). Instances of this have been observed, for example, when 382 a library truncates a UTF-16 string without checking whether the 383 truncation split a surrogate pair. The behavior of software that 384 receives JSON texts containing such values is unpredictable; for 385 example, implementations might return different values for the length 386 of a string value or even suffer fatal runtime exceptions. 388 8.3. String Comparison 390 Software implementations are typically required to test names of 391 object members for equality. Implementations that transform the 392 textual representation into sequences of Unicode code units and then 393 perform the comparison numerically, code unit by code unit, are 394 interoperable in the sense that implementations will agree in all 395 cases on equality or inequality of two strings. For example, 396 implementations that compare strings with escaped characters 397 unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not 398 equal. 400 9. Parsers 402 A JSON parser transforms a JSON text into another representation. A 403 JSON parser MUST accept all texts that conform to the JSON grammar. 404 A JSON parser MAY accept non-JSON forms or extensions. 406 An implementation may set limits on the size of texts that it 407 accepts. An implementation may set limits on the maximum depth of 408 nesting. An implementation may set limits on the range and precision 409 of numbers. An implementation may set limits on the length and 410 character contents of strings. 412 10. Generators 414 A JSON generator produces JSON text. The resulting text MUST 415 strictly conform to the JSON grammar. 417 11. IANA Considerations 419 The MIME media type for JSON text is application/json. 421 Type name: application 423 Subtype name: json 425 Required parameters: n/a 427 Optional parameters: n/a 429 Encoding considerations: binary 431 Security considerations: See [RFC7159], Section 12. 433 Interoperability considerations: Described in [RFC7159] 435 Published specification: [RFC7159] 437 Applications that use this media type: 438 JSON has been used to exchange data between applications written 439 in all of these programming languages: ActionScript, C, C#, 440 Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, 441 Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and 442 Scheme. 444 Additional information: 445 Magic number(s): n/a 446 File extension(s): .json 447 Macintosh file type code(s): TEXT 449 Person & email address to contact for further information: 450 IESG 451 453 Intended usage: COMMON 455 Restrictions on usage: none 456 Author: 457 Douglas Crockford 458 460 Change controller: 461 IESG 462 464 Note: No "charset" parameter is defined for this registration. 465 Adding one really has no effect on compliant recipients. 467 12. Security Considerations 469 Generally, there are security issues with scripting languages. JSON 470 is a subset of JavaScript but excludes assignment and invocation. 472 Since JSON's syntax is borrowed from JavaScript, it is possible to 473 use that language's "eval()" function to parse most JSON texts (but 474 not all; certain characters such as U+2028 LINE SEPARATOR and U+2029 475 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript). This 476 generally constitutes an unacceptable security risk, since the text 477 could contain executable code along with data declarations. The same 478 consideration applies to the use of eval()-like functions in any 479 other programming language in which JSON texts conform to that 480 language's syntax. 482 13. Examples 484 This is a JSON object: 486 { 487 "Image": { 488 "Width": 800, 489 "Height": 600, 490 "Title": "View from 15th Floor", 491 "Thumbnail": { 492 "Url": "http://www.example.com/image/481989943", 493 "Height": 125, 494 "Width": 100 495 }, 496 "Animated" : false, 497 "IDs": [116, 943, 234, 38793] 498 } 499 } 501 Its Image member is an object whose Thumbnail member is an object and 502 whose IDs member is an array of numbers. 504 This is a JSON array containing two objects: 506 [ 507 { 508 "precision": "zip", 509 "Latitude": 37.7668, 510 "Longitude": -122.3959, 511 "Address": "", 512 "City": "SAN FRANCISCO", 513 "State": "CA", 514 "Zip": "94107", 515 "Country": "US" 516 }, 517 { 518 "precision": "zip", 519 "Latitude": 37.371991, 520 "Longitude": -122.026020, 521 "Address": "", 522 "City": "SUNNYVALE", 523 "State": "CA", 524 "Zip": "94085", 525 "Country": "US" 526 } 527 ] 529 Here are three small JSON texts containing only values: 531 "Hello world!" 533 42 535 true 537 14. Contributors 539 RFC 4627 was written by Douglas Crockford. This document was 540 constructed by making a relatively small number of changes to that 541 document; thus, the vast majority of the text here is his. 543 15. References 545 15.1. Normative References 547 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 548 Standard 754, August 2008, 549 . 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 555 Specifications: ABNF", STD 68, RFC 5234, January 2008. 557 [UNICODE] The Unicode Consortium, "The Unicode Standard", 558 . 560 15.2. Informative References 562 [ECMA-262] 563 Ecma International, "ECMAScript Language Specification 564 Edition 5.1", Standard ECMA-262, June 2011, 565 . 568 [ECMA-404] 569 Ecma International, "The JSON Data Interchange Format", 570 Standard ECMA-404, October 2013, 571 . 574 [Err3607] RFC Errata, "Errata ID 3607", RFC 4627, 575 . 577 [Err3915] RFC Errata, "Errata ID 7159", RFC 7159, 578 . 580 [Err4264] RFC Errata, "Errata ID 7159", RFC 7159, 581 . 583 [Err4336] RFC Errata, "Errata ID 7159", RFC 7159, 584 . 586 [Err607] RFC Errata, "Errata ID 607", RFC 4627, 587 . 589 [RFC4627] Crockford, D., "The application/json Media Type for 590 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 592 Appendix A. Changes from RFC 4627 594 This section lists changes between this document and the text in RFC 595 4627. 597 o Changed the title and abstract of the document. 599 o Changed the reference to [UNICODE] to be not version specific. 601 o Added a "Specifications of JSON" section. 603 o Added an "Introduction to This Revision" section. 605 o Changed the definition of "JSON text" so that it can be any JSON 606 value, removing the constraint that it be an object or array. 608 o Added language about duplicate object member names, member 609 ordering, and interoperability. 611 o Clarified the absence of a requirement that values in an array be 612 of the same JSON type. 614 o Applied erratum #607 from RFC 4627 to correctly align the artwork 615 for the definition of "object". 617 o Changed "as sequences of digits" to "in the grammar below" in the 618 "Numbers" section, and made base-10-ness explicit. 620 o Added language about number interoperability as a function of 621 IEEE754, and added an IEEE754 reference. 623 o Added language about interoperability and Unicode characters and 624 about string comparisons. To do this, turned the old "Encoding" 625 section into a "String and Character Issues" section, with three 626 subsections: "Character Encoding", "Unicode Characters", and 627 "String Comparison". 629 o Removed method of detection of character encoding from section 3 630 "Encoding" of RFC 4627. 632 o Changed guidance in the "Parsers" section to point out that 633 implementations may set limits on the range "and precision" of 634 numbers. 636 o Updated and tidied the "IANA Considerations" section. 638 o Made a real "Security Considerations" section and lifted the text 639 out of the previous "IANA Considerations" section. 641 o Applied erratum #3607 from RFC 4627 by removing the security 642 consideration that begins "A JSON text can be safely passed" and 643 the JavaScript code that went with that consideration. 645 o Added a note to the "Security Considerations" section pointing out 646 the risks of using the "eval()" function in JavaScript or any 647 other language in which JSON texts conform to that language's 648 syntax. 650 o Added a note to the "IANA Considerations" clarifying the absence 651 of a "charset" parameter for the application/json media type. 653 o Changed "100" to 100 and added a boolean field, both in the first 654 example. 656 o Added examples of JSON texts with simple values, neither objects 657 nor arrays. 659 o Added a "Contributors" section crediting Douglas Crockford. 661 o Added a reference to RFC 4627. 663 o Moved the ECMAScript reference from Normative to Informative and 664 updated it to reference ECMAScript 5.1, and added a reference to 665 ECMA 404. 667 Author's Address 669 Tim Bray (editor) 670 Textuality 672 EMail: tbray@textuality.com