idnits 2.17.1 draft-ietf-jsonbis-rfc7159bis-04.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 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 (July 17, 2017) is 2447 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: 'THIS DOC' is mentioned on line 455, but not defined -- Looks like a reference, but probably isn't: '116' on line 517 -- Looks like a reference, but probably isn't: '943' on line 517 -- Looks like a reference, but probably isn't: '234' on line 517 -- Looks like a reference, but probably isn't: '38793' on line 517 -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA-404' -- 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JSONbis T. Bray, Ed. 3 Internet-Draft Textuality 4 Obsoletes: 7159 (if approved) July 17, 2017 5 Intended status: Standards Track 6 Expires: January 18, 2018 8 The JavaScript Object Notation (JSON) Data Interchange Format 9 draft-ietf-jsonbis-rfc7159bis-04 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 January 18, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 13 91 15.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 15 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 JavaScript Object Notation (JSON) is a text format for the 98 serialization of structured data. It is derived from the object 99 literals of JavaScript, as defined in the ECMAScript Programming 100 Language Standard, Third Edition [ECMA-262]. 102 JSON can represent four primitive types (strings, numbers, booleans, 103 and null) and two structured types (objects and arrays). 105 A string is a sequence of zero or more Unicode characters [UNICODE]. 106 Note that this citation references the latest version of Unicode 107 rather than a specific release. It is not expected that future 108 changes in the UNICODE specification will impact the syntax of JSON. 110 An object is an unordered collection of zero or more name/value 111 pairs, where a name is a string and a value is a string, number, 112 boolean, null, object, or array. 114 An array is an ordered sequence of zero or more values. 116 The terms "object" and "array" come from the conventions of 117 JavaScript. 119 JSON's design goals were for it to be minimal, portable, textual, and 120 a subset of JavaScript. 122 1.1. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 The grammatical rules in this document are to be interpreted as 129 described in [RFC5234]. 131 1.2. Specifications of JSON 133 This document updates [RFC4627], which describes JSON and registers 134 the media type "application/json". 136 JSON is also described in [ECMA-404]. 138 The reference to ECMA-404 in the previous sentence is normative, not 139 with the usual meaning that implementors need to consult it in order 140 to understand this document, but to emphasize that there are no 141 inconsistencies in the definition of the term "JSON text" in any of 142 its specifications. Note, however, that ECMA-404 allows several 143 practices which this specification recommends avoiding in the 144 interests of maximal interoperability. 146 The intent is that the grammar is the same between the two documents, 147 although different descriptions are used. If there a difference is 148 found between them, ECMA and the IETF will work together to update 149 both documents. 151 If an error is found with either document, the other should be 152 examined to see if it has a similar error, and fixed if possible. 154 If either document is changed in the future, ECMA and the IETF will 155 work together to ensure that the two documents stay aligned through 156 the change. 158 1.3. Introduction to This Revision 160 In the years since the publication of RFC 4627, JSON has found very 161 wide use. This experience has revealed certain patterns, which, 162 while allowed by its specifications, have caused interoperability 163 problems. 165 Also, a small number of errata have been reported to RFC4627 (see RFC 166 Errata IDs 607 [Err607] and 3607 [Err3607]) and to RFC7159 (see RFC 167 Errata IDs [Err3915], [Err4264], and [Err4336]). 169 This document's goal is to apply the errata, remove inconsistencies 170 with other specifications of JSON, and highlight practices that can 171 lead to interoperability problems. 173 2. JSON Grammar 175 A JSON text is a sequence of tokens. The set of tokens includes six 176 structural characters, strings, numbers, and three literal names. 178 A JSON text is a serialized value. Note that certain previous 179 specifications of JSON constrained a JSON text to be an object or an 180 array. Implementations that generate only objects or arrays where a 181 JSON text is called for will be interoperable in the sense that all 182 implementations will accept these as conforming JSON texts. 184 JSON-text = ws value ws 186 These are the six structural characters: 188 begin-array = ws %x5B ws ; [ left square bracket 190 begin-object = ws %x7B ws ; { left curly bracket 192 end-array = ws %x5D ws ; ] right square bracket 194 end-object = ws %x7D ws ; } right curly bracket 196 name-separator = ws %x3A ws ; : colon 198 value-separator = ws %x2C ws ; , comma 200 Insignificant whitespace is allowed before or after any of the six 201 structural characters. 203 ws = *( 204 %x20 / ; Space 205 %x09 / ; Horizontal tab 206 %x0A / ; Line feed or New line 207 %x0D ) ; Carriage return 209 3. Values 211 A JSON value MUST be an object, array, number, or string, or one of 212 the following three literal names: 214 false null true 216 The literal names MUST be lowercase. No other literal names are 217 allowed. 219 value = false / null / true / object / array / number / string 221 false = %x66.61.6c.73.65 ; false 223 null = %x6e.75.6c.6c ; null 225 true = %x74.72.75.65 ; true 227 4. Objects 229 An object structure is represented as a pair of curly brackets 230 surrounding zero or more name/value pairs (or members). A name is a 231 string. A single colon comes after each name, separating the name 232 from the value. A single comma separates a value from a following 233 name. The names within an object SHOULD be unique. 235 object = begin-object [ member *( value-separator member ) ] 236 end-object 238 member = string name-separator value 240 An object whose names are all unique is interoperable in the sense 241 that all software implementations receiving that object will agree on 242 the name-value mappings. When the names within an object are not 243 unique, the behavior of software that receives such an object is 244 unpredictable. Many implementations report the last name/value pair 245 only. Other implementations report an error or fail to parse the 246 object, and some implementations report all of the name/value pairs, 247 including duplicates. 249 JSON parsing libraries have been observed to differ as to whether or 250 not they make the ordering of object members visible to calling 251 software. Implementations whose behavior does not depend on member 252 ordering will be interoperable in the sense that they will not be 253 affected by these differences. 255 5. Arrays 257 An array structure is represented as square brackets surrounding zero 258 or more values (or elements). Elements are separated by commas. 260 array = begin-array [ value *( value-separator value ) ] end-array 262 There is no requirement that the values in an array be of the same 263 type. 265 6. Numbers 267 The representation of numbers is similar to that used in most 268 programming languages. A number is represented in base 10 using 269 decimal digits. It contains an integer component that may be 270 prefixed with an optional minus sign, which may be followed by a 271 fraction part and/or an exponent part. Leading zeros are not 272 allowed. 274 A fraction part is a decimal point followed by one or more digits. 276 An exponent part begins with the letter E in upper or lower case, 277 which may be followed by a plus or minus sign. The E and optional 278 sign are followed by one or more digits. 280 Numeric values that cannot be represented in the grammar below (such 281 as Infinity and NaN) are not permitted. 283 number = [ minus ] int [ frac ] [ exp ] 285 decimal-point = %x2E ; . 287 digit1-9 = %x31-39 ; 1-9 289 e = %x65 / %x45 ; e E 291 exp = e [ minus / plus ] 1*DIGIT 293 frac = decimal-point 1*DIGIT 295 int = zero / ( digit1-9 *DIGIT ) 297 minus = %x2D ; - 299 plus = %x2B ; + 301 zero = %x30 ; 0 303 This specification allows implementations to set limits on the range 304 and precision of numbers accepted. Since software that implements 305 IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is 306 generally available and widely used, good interoperability can be 307 achieved by implementations that expect no more precision or range 308 than these provide, in the sense that implementations will 309 approximate JSON numbers within the expected precision. A JSON 310 number such as 1E400 or 3.141592653589793238462643383279 may indicate 311 potential interoperability problems, since it suggests that the 312 software that created it expects receiving software to have greater 313 capabilities for numeric magnitude and precision than is widely 314 available. 316 Note that when such software is used, numbers that are integers and 317 are in the range [-(2**53)+1, (2**53)-1] are interoperable in the 318 sense that implementations will agree exactly on their numeric 319 values. 321 7. Strings 323 The representation of strings is similar to conventions used in the C 324 family of programming languages. A string begins and ends with 325 quotation marks. All Unicode characters may be placed within the 326 quotation marks, except for the characters that must be escaped: 327 quotation mark, reverse solidus, and the control characters (U+0000 328 through U+001F). 330 Any character may be escaped. If the character is in the Basic 331 Multilingual Plane (U+0000 through U+FFFF), then it may be 332 represented as a six-character sequence: a reverse solidus, followed 333 by the lowercase letter u, followed by four hexadecimal digits that 334 encode the character's code point. The hexadecimal letters A though 335 F can be upper or lower case. So, for example, a string containing 336 only a single reverse solidus character may be represented as 337 "\u005C". 339 Alternatively, there are two-character sequence escape 340 representations of some popular characters. So, for example, a 341 string containing only a single reverse solidus character may be 342 represented more compactly as "\\". 344 To escape an extended character that is not in the Basic Multilingual 345 Plane, the character is represented as a 12-character sequence, 346 encoding the UTF-16 surrogate pair. So, for example, a string 347 containing only the G clef character (U+1D11E) may be represented as 348 "\uD834\uDD1E". 350 string = quotation-mark *char quotation-mark 352 char = unescaped / 353 escape ( 354 %x22 / ; " quotation mark U+0022 355 %x5C / ; \ reverse solidus U+005C 356 %x2F / ; / solidus U+002F 357 %x62 / ; b backspace U+0008 358 %x66 / ; f form feed U+000C 359 %x6E / ; n line feed U+000A 360 %x72 / ; r carriage return U+000D 361 %x74 / ; t tab U+0009 362 %x75 4HEXDIG ) ; uXXXX U+XXXX 364 escape = %x5C ; \ 366 quotation-mark = %x22 ; " 368 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 370 8. String and Character Issues 372 8.1. Character Encoding 374 When transmitting over a network protocol, or as a payload of a 375 network protocol intended to be interpreted as part of a protocol, 376 JSON text MUST be encoded in UTF-8 (Section 3 of [UNICODE]). 378 Previous specifications of JSON have not required the use of UTF-8 379 when transmitting JSON text. However, the vast majority of JSON- 380 based software implementations have chosen to use the UTF-8 encoding, 381 to the extent that it is the only encoding that achieves 382 interoperability. 384 Implementations MUST NOT add a byte order mark (U+FEFF) to the 385 beginning of a networked-transmitted JSON text. In the interests of 386 interoperability, implementations that parse JSON texts MAY ignore 387 the presence of a byte order mark rather than treating it as an 388 error. 390 8.2. Unicode Characters 392 When all the strings represented in a JSON text are composed entirely 393 of Unicode characters [UNICODE] (however escaped), then that JSON 394 text is interoperable in the sense that all software implementations 395 that parse it will agree on the contents of names and of string 396 values in objects and arrays. 398 However, the ABNF in this specification allows member names and 399 string values to contain bit sequences that cannot encode Unicode 400 characters; for example, "\uDEAD" (a single unpaired UTF-16 401 surrogate). Instances of this have been observed, for example, when 402 a library truncates a UTF-16 string without checking whether the 403 truncation split a surrogate pair. The behavior of software that 404 receives JSON texts containing such values is unpredictable; for 405 example, implementations might return different values for the length 406 of a string value or even suffer fatal runtime exceptions. 408 8.3. String Comparison 410 Software implementations are typically required to test names of 411 object members for equality. Implementations that transform the 412 textual representation into sequences of Unicode code units and then 413 perform the comparison numerically, code unit by code unit, are 414 interoperable in the sense that implementations will agree in all 415 cases on equality or inequality of two strings. For example, 416 implementations that compare strings with escaped characters 417 unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not 418 equal. 420 9. Parsers 422 A JSON parser transforms a JSON text into another representation. A 423 JSON parser MUST accept all texts that conform to the JSON grammar. 424 A JSON parser MAY accept non-JSON forms or extensions. 426 An implementation may set limits on the size of texts that it 427 accepts. An implementation may set limits on the maximum depth of 428 nesting. An implementation may set limits on the range and precision 429 of numbers. An implementation may set limits on the length and 430 character contents of strings. 432 10. Generators 434 A JSON generator produces JSON text. The resulting text MUST 435 strictly conform to the JSON grammar. 437 11. IANA Considerations 439 The MIME media type for JSON text is application/json. 441 Type name: application 443 Subtype name: json 445 Required parameters: n/a 447 Optional parameters: n/a 449 Encoding considerations: binary 451 Security considerations: See [THIS DOC], Section 12. 453 Interoperability considerations: Described in [THIS DOC] 455 Published specification: [THIS DOC] 457 Applications that use this media type: 458 JSON has been used to exchange data between applications written 459 in all of these programming languages: ActionScript, C, C#, 460 Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, 461 Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and 462 Scheme. 464 Additional information: 465 Magic number(s): n/a 466 File extension(s): .json 467 Macintosh file type code(s): TEXT 469 Person & email address to contact for further information: 470 IESG 471 473 Intended usage: COMMON 474 Restrictions on usage: none 476 Author: 477 Douglas Crockford 478 480 Change controller: 481 IESG 482 484 Note: No "charset" parameter is defined for this registration. 485 Adding one really has no effect on compliant recipients. 487 12. Security Considerations 489 Generally, there are security issues with scripting languages. JSON 490 is a subset of JavaScript but excludes assignment and invocation. 492 Since JSON's syntax is borrowed from JavaScript, it is possible to 493 use that language's "eval()" function to parse most JSON texts (but 494 not all; certain characters such as U+2028 LINE SEPARATOR and U+2029 495 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript). This 496 generally constitutes an unacceptable security risk, since the text 497 could contain executable code along with data declarations. The same 498 consideration applies to the use of eval()-like functions in any 499 other programming language in which JSON texts conform to that 500 language's syntax. 502 13. Examples 504 This is a JSON object: 506 { 507 "Image": { 508 "Width": 800, 509 "Height": 600, 510 "Title": "View from 15th Floor", 511 "Thumbnail": { 512 "Url": "http://www.example.com/image/481989943", 513 "Height": 125, 514 "Width": 100 515 }, 516 "Animated" : false, 517 "IDs": [116, 943, 234, 38793] 518 } 519 } 521 Its Image member is an object whose Thumbnail member is an object and 522 whose IDs member is an array of numbers. 524 This is a JSON array containing two objects: 526 [ 527 { 528 "precision": "zip", 529 "Latitude": 37.7668, 530 "Longitude": -122.3959, 531 "Address": "", 532 "City": "SAN FRANCISCO", 533 "State": "CA", 534 "Zip": "94107", 535 "Country": "US" 536 }, 537 { 538 "precision": "zip", 539 "Latitude": 37.371991, 540 "Longitude": -122.026020, 541 "Address": "", 542 "City": "SUNNYVALE", 543 "State": "CA", 544 "Zip": "94085", 545 "Country": "US" 546 } 547 ] 549 Here are three small JSON texts containing only values: 551 "Hello world!" 553 42 555 true 557 14. Contributors 559 RFC 4627 was written by Douglas Crockford. This document was 560 constructed by making a relatively small number of changes to that 561 document; thus, the vast majority of the text here is his. 563 15. References 564 15.1. Normative References 566 [ECMA-404] 567 Ecma International, "The JSON Data Interchange Format", 568 Standard ECMA-404, October 2013, . 571 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 572 Standard 754, August 2008, 573 . 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 581 Specifications: ABNF", STD 68, RFC 5234, 582 DOI 10.17487/RFC5234, January 2008, 583 . 585 [UNICODE] The Unicode Consortium, "The Unicode Standard", 586 . 588 15.2. Informative References 590 [ECMA-262] 591 Ecma International, "ECMAScript Language Specification, 592 Third Edition", Standard ECMA-262, December 1999, 593 . 597 [Err3607] RFC Errata, "Errata ID 3607", RFC 4627, . 600 [Err3915] RFC Errata, "Errata ID 7159", RFC 7159, . 603 [Err4264] RFC Errata, "Errata ID 7159", RFC 7159, . 606 [Err4336] RFC Errata, "Errata ID 7159", RFC 7159, . 609 [Err607] RFC Errata, "Errata ID 607", RFC 4627, . 612 [RFC4627] Crockford, D., "The application/json Media Type for 613 JavaScript Object Notation (JSON)", RFC 4627, 614 DOI 10.17487/RFC4627, July 2006, 615 . 617 Appendix A. Changes from RFC 7159 619 This section lists changes between this document and the text in RFC 620 RFC7159. 622 o Section 1.2 has been updated to reflect the removal of a JSON 623 specification from ECMA-262, to make the reference to ECMA-404 624 normative, and to explain the particular meaning of "normative". 626 o Section 1.3 has been updated to reflect errata filed against 627 RFC7159, not RFC4627. 629 o Section 8.1 was changed to require the use of UTF-8 when 630 transmitted over a network. 632 o Section 12 has been updated to increase the precision of the 633 description of the security risk that follows from using the 634 ECMAScript "eval()" function. 636 o Section 15.1 has been updated to include ECMA 404 as a normative 637 reference. 639 o Section 15.2 has been updated to remove ECMA 404, update the 640 version of ECMA-262, and refresh the errata list. 642 Author's Address 644 Tim Bray (editor) 645 Textuality 647 EMail: tbray@textuality.com