idnits 2.17.1 draft-ietf-jsonbis-rfc7159bis-03.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 (February 19, 2017) is 2616 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 450, but not defined -- Looks like a reference, but probably isn't: '116' on line 512 -- Looks like a reference, but probably isn't: '943' on line 512 -- Looks like a reference, but probably isn't: '234' on line 512 -- Looks like a reference, but probably isn't: '38793' on line 512 -- 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 (==), 21 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) February 19, 2017 5 Intended status: Standards Track 6 Expires: August 23, 2017 8 The JavaScript Object Notation (JSON) Data Interchange Format 9 draft-ietf-jsonbis-rfc7159bis-03 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 August 23, 2017. 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 . . . . . . . . . . . . . . . . . . 12 91 15.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Changes from RFC 7159 . . . . . . . . . . . . . . . 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 JSON is also described in [ECMA-404]. 137 The reference to ECMA-404 in the previous sentence is normative, not 138 with the usual meaning that implementors need to consult it in order 139 to understand this document, but to emphasize that there are no 140 inconsistencies in the definition of the term "JSON text" in any of 141 its specifications. Note, however, that ECMA-404 allows several 142 practices which this specification recommends avoiding in the 143 interests of maximal interoperability. 145 The intent is that the grammar is the same between the two documents, 146 although different descriptions are used. If there a difference is 147 found between them, ECMA and the IETF will work together to update 148 both documents. 150 If an error is found with either document, the other should be 151 examined to see if it has a similar error, and fixed if possible. 153 If either document is changed in the future, ECMA and the IETF will 154 work together to ensure that the two documents stay aligned through 155 the change. 157 1.3. Introduction to This Revision 159 In the years since the publication of RFC 4627, JSON has found very 160 wide use. This experience has revealed certain patterns, which, 161 while allowed by its specifications, have caused interoperability 162 problems. 164 Also, a small number of errata have been reported to RFC4627 (see RFC 165 Errata IDs 607 [Err607] and 3607 [Err3607]) and to RFC7159 (see RFC 166 Errata IDs [Err3915], [Err4264], and [Err4336]). 168 This document's goal is to apply the errata, remove inconsistencies 169 with other specifications of JSON, and highlight practices that can 170 lead to interoperability problems. 172 2. JSON Grammar 174 A JSON text is a sequence of tokens. The set of tokens includes six 175 structural characters, strings, numbers, and three literal names. 177 A JSON text is a serialized value. Note that certain previous 178 specifications of JSON constrained a JSON text to be an object or an 179 array. Implementations that generate only objects or arrays where a 180 JSON text is called for will be interoperable in the sense that all 181 implementations will accept these as conforming JSON texts. 183 JSON-text = ws value ws 185 These are the six structural characters: 187 begin-array = ws %x5B ws ; [ left square bracket 189 begin-object = ws %x7B ws ; { left curly bracket 191 end-array = ws %x5D ws ; ] right square bracket 193 end-object = ws %x7D ws ; } right curly bracket 195 name-separator = ws %x3A ws ; : colon 197 value-separator = ws %x2C ws ; , comma 199 Insignificant whitespace is allowed before or after any of the six 200 structural characters. 202 ws = *( 203 %x20 / ; Space 204 %x09 / ; Horizontal tab 205 %x0A / ; Line feed or New line 206 %x0D ) ; Carriage return 208 3. Values 210 A JSON value MUST be an object, array, number, or string, or one of 211 the following three literal names: 213 false null true 215 The literal names MUST be lowercase. No other literal names are 216 allowed. 218 value = false / null / true / object / array / number / string 220 false = %x66.61.6c.73.65 ; false 222 null = %x6e.75.6c.6c ; null 224 true = %x74.72.75.65 ; true 226 4. Objects 228 An object structure is represented as a pair of curly brackets 229 surrounding zero or more name/value pairs (or members). A name is a 230 string. A single colon comes after each name, separating the name 231 from the value. A single comma separates a value from a following 232 name. The names within an object SHOULD be unique. 234 object = begin-object [ member *( value-separator member ) ] 235 end-object 237 member = string name-separator value 239 An object whose names are all unique is interoperable in the sense 240 that all software implementations receiving that object will agree on 241 the name-value mappings. When the names within an object are not 242 unique, the behavior of software that receives such an object is 243 unpredictable. Many implementations report the last name/value pair 244 only. Other implementations report an error or fail to parse the 245 object, and some implementations report all of the name/value pairs, 246 including duplicates. 248 JSON parsing libraries have been observed to differ as to whether or 249 not they make the ordering of object members visible to calling 250 software. Implementations whose behavior does not depend on member 251 ordering will be interoperable in the sense that they will not be 252 affected by these differences. 254 5. Arrays 256 An array structure is represented as square brackets surrounding zero 257 or more values (or elements). Elements are separated by commas. 259 array = begin-array [ value *( value-separator value ) ] end-array 261 There is no requirement that the values in an array be of the same 262 type. 264 6. Numbers 266 The representation of numbers is similar to that used in most 267 programming languages. A number is represented in base 10 using 268 decimal digits. It contains an integer component that may be 269 prefixed with an optional minus sign, which may be followed by a 270 fraction part and/or an exponent part. Leading zeros are not 271 allowed. 273 A fraction part is a decimal point followed by one or more digits. 275 An exponent part begins with the letter E in upper or lower case, 276 which may be followed by a plus or minus sign. The E and optional 277 sign are followed by one or more digits. 279 Numeric values that cannot be represented in the grammar below (such 280 as Infinity and NaN) are not permitted. 282 number = [ minus ] int [ frac ] [ exp ] 284 decimal-point = %x2E ; . 286 digit1-9 = %x31-39 ; 1-9 288 e = %x65 / %x45 ; e E 290 exp = e [ minus / plus ] 1*DIGIT 292 frac = decimal-point 1*DIGIT 294 int = zero / ( digit1-9 *DIGIT ) 296 minus = %x2D ; - 298 plus = %x2B ; + 300 zero = %x30 ; 0 302 This specification allows implementations to set limits on the range 303 and precision of numbers accepted. Since software that implements 304 IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is 305 generally available and widely used, good interoperability can be 306 achieved by implementations that expect no more precision or range 307 than these provide, in the sense that implementations will 308 approximate JSON numbers within the expected precision. A JSON 309 number such as 1E400 or 3.141592653589793238462643383279 may indicate 310 potential interoperability problems, since it suggests that the 311 software that created it expects receiving software to have greater 312 capabilities for numeric magnitude and precision than is widely 313 available. 315 Note that when such software is used, numbers that are integers and 316 are in the range [-(2**53)+1, (2**53)-1] are interoperable in the 317 sense that implementations will agree exactly on their numeric 318 values. 320 7. Strings 322 The representation of strings is similar to conventions used in the C 323 family of programming languages. A string begins and ends with 324 quotation marks. All Unicode characters may be placed within the 325 quotation marks, except for the characters that must be escaped: 326 quotation mark, reverse solidus, and the control characters (U+0000 327 through U+001F). 329 Any character may be escaped. If the character is in the Basic 330 Multilingual Plane (U+0000 through U+FFFF), then it may be 331 represented as a six-character sequence: a reverse solidus, followed 332 by the lowercase letter u, followed by four hexadecimal digits that 333 encode the character's code point. The hexadecimal letters A though 334 F can be upper or lower case. So, for example, a string containing 335 only a single reverse solidus character may be represented as 336 "\u005C". 338 Alternatively, there are two-character sequence escape 339 representations of some popular characters. So, for example, a 340 string containing only a single reverse solidus character may be 341 represented more compactly as "\\". 343 To escape an extended character that is not in the Basic Multilingual 344 Plane, the character is represented as a 12-character sequence, 345 encoding the UTF-16 surrogate pair. So, for example, a string 346 containing only the G clef character (U+1D11E) may be represented as 347 "\uD834\uDD1E". 349 string = quotation-mark *char quotation-mark 351 char = unescaped / 352 escape ( 353 %x22 / ; " quotation mark U+0022 354 %x5C / ; \ reverse solidus U+005C 355 %x2F / ; / solidus U+002F 356 %x62 / ; b backspace U+0008 357 %x66 / ; f form feed U+000C 358 %x6E / ; n line feed U+000A 359 %x72 / ; r carriage return U+000D 360 %x74 / ; t tab U+0009 361 %x75 4HEXDIG ) ; uXXXX U+XXXX 363 escape = %x5C ; \ 365 quotation-mark = %x22 ; " 367 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 369 8. String and Character Issues 371 8.1. Character Encoding 373 JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] 374 (Section 3). The default encoding is UTF-8, and JSON texts that are 375 encoded in UTF-8 are interoperable in the sense that they will be 376 read successfully by the maximum number of implementations; there are 377 many implementations that cannot successfully read texts in other 378 encodings (such as UTF-16 and UTF-32). 380 Implementations MUST NOT add a byte order mark (U+FEFF) to the 381 beginning of a JSON text. In the interests of interoperability, 382 implementations that parse JSON texts MAY ignore the presence of a 383 byte order mark rather than treating it as an error. 385 8.2. Unicode Characters 387 When all the strings represented in a JSON text are composed entirely 388 of Unicode characters [UNICODE] (however escaped), then that JSON 389 text is interoperable in the sense that all software implementations 390 that parse it will agree on the contents of names and of string 391 values in objects and arrays. 393 However, the ABNF in this specification allows member names and 394 string values to contain bit sequences that cannot encode Unicode 395 characters; for example, "\uDEAD" (a single unpaired UTF-16 396 surrogate). Instances of this have been observed, for example, when 397 a library truncates a UTF-16 string without checking whether the 398 truncation split a surrogate pair. The behavior of software that 399 receives JSON texts containing such values is unpredictable; for 400 example, implementations might return different values for the length 401 of a string value or even suffer fatal runtime exceptions. 403 8.3. String Comparison 405 Software implementations are typically required to test names of 406 object members for equality. Implementations that transform the 407 textual representation into sequences of Unicode code units and then 408 perform the comparison numerically, code unit by code unit, are 409 interoperable in the sense that implementations will agree in all 410 cases on equality or inequality of two strings. For example, 411 implementations that compare strings with escaped characters 412 unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not 413 equal. 415 9. Parsers 417 A JSON parser transforms a JSON text into another representation. A 418 JSON parser MUST accept all texts that conform to the JSON grammar. 419 A JSON parser MAY accept non-JSON forms or extensions. 421 An implementation may set limits on the size of texts that it 422 accepts. An implementation may set limits on the maximum depth of 423 nesting. An implementation may set limits on the range and precision 424 of numbers. An implementation may set limits on the length and 425 character contents of strings. 427 10. Generators 429 A JSON generator produces JSON text. The resulting text MUST 430 strictly conform to the JSON grammar. 432 11. IANA Considerations 434 The MIME media type for JSON text is application/json. 436 Type name: application 438 Subtype name: json 440 Required parameters: n/a 442 Optional parameters: n/a 444 Encoding considerations: binary 446 Security considerations: See [THIS DOC], Section 12. 448 Interoperability considerations: Described in [THIS DOC] 450 Published specification: [THIS DOC] 452 Applications that use this media type: 453 JSON has been used to exchange data between applications written 454 in all of these programming languages: ActionScript, C, C#, 455 Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, 456 Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and 457 Scheme. 459 Additional information: 460 Magic number(s): n/a 461 File extension(s): .json 462 Macintosh file type code(s): TEXT 464 Person & email address to contact for further information: 465 IESG 466 468 Intended usage: COMMON 470 Restrictions on usage: none 471 Author: 472 Douglas Crockford 473 475 Change controller: 476 IESG 477 479 Note: No "charset" parameter is defined for this registration. 480 Adding one really has no effect on compliant recipients. 482 12. Security Considerations 484 Generally, there are security issues with scripting languages. JSON 485 is a subset of JavaScript but excludes assignment and invocation. 487 Since JSON's syntax is borrowed from JavaScript, it is possible to 488 use that language's "eval()" function to parse most JSON texts (but 489 not all; certain characters such as U+2028 LINE SEPARATOR and U+2029 490 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript). This 491 generally constitutes an unacceptable security risk, since the text 492 could contain executable code along with data declarations. The same 493 consideration applies to the use of eval()-like functions in any 494 other programming language in which JSON texts conform to that 495 language's syntax. 497 13. Examples 499 This is a JSON object: 501 { 502 "Image": { 503 "Width": 800, 504 "Height": 600, 505 "Title": "View from 15th Floor", 506 "Thumbnail": { 507 "Url": "http://www.example.com/image/481989943", 508 "Height": 125, 509 "Width": 100 510 }, 511 "Animated" : false, 512 "IDs": [116, 943, 234, 38793] 513 } 514 } 516 Its Image member is an object whose Thumbnail member is an object and 517 whose IDs member is an array of numbers. 519 This is a JSON array containing two objects: 521 [ 522 { 523 "precision": "zip", 524 "Latitude": 37.7668, 525 "Longitude": -122.3959, 526 "Address": "", 527 "City": "SAN FRANCISCO", 528 "State": "CA", 529 "Zip": "94107", 530 "Country": "US" 531 }, 532 { 533 "precision": "zip", 534 "Latitude": 37.371991, 535 "Longitude": -122.026020, 536 "Address": "", 537 "City": "SUNNYVALE", 538 "State": "CA", 539 "Zip": "94085", 540 "Country": "US" 541 } 542 ] 544 Here are three small JSON texts containing only values: 546 "Hello world!" 548 42 550 true 552 14. Contributors 554 RFC 4627 was written by Douglas Crockford. This document was 555 constructed by making a relatively small number of changes to that 556 document; thus, the vast majority of the text here is his. 558 15. References 560 15.1. Normative References 562 [ECMA-404] 563 Ecma International, "The JSON Data Interchange Format", 564 Standard ECMA-404, October 2013, 565 . 568 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 569 Standard 754, August 2008, 570 . 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 576 Specifications: ABNF", STD 68, RFC 5234, January 2008. 578 [UNICODE] The Unicode Consortium, "The Unicode Standard", 579 . 581 15.2. Informative References 583 [ECMA-262] 584 Ecma International, "ECMAScript Language Specification, 585 Third Edition", Standard ECMA-262, December 1999, 586 . 590 [Err3607] RFC Errata, "Errata ID 3607", RFC 4627, 591 . 593 [Err3915] RFC Errata, "Errata ID 7159", RFC 7159, 594 . 596 [Err4264] RFC Errata, "Errata ID 7159", RFC 7159, 597 . 599 [Err4336] RFC Errata, "Errata ID 7159", RFC 7159, 600 . 602 [Err607] RFC Errata, "Errata ID 607", RFC 4627, 603 . 605 [RFC4627] Crockford, D., "The application/json Media Type for 606 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 608 Appendix A. Changes from RFC 7159 610 This section lists changes between this document and the text in RFC 611 RFC7159. 613 o Section 1.2 has been updated to reflect the removal of a JSON 614 specification from ECMA-262, to make the reference to ECMA-404 615 normative, and to explain the particular meaning of "normative". 617 o Section 1.3 has been updated to reflect errata filed against 618 RFC7159, not RFC4627. 620 o Section 12 has been updated to increase the precision of the 621 description of the security risk that follows from using the 622 ECMAScript "eval()" function. 624 o Section 15.1 has been updated to include ECMA 404 as a normative 625 reference. 627 o Section 15.2 has been updated to remove ECMA 404, update the 628 version of ECMA-262, and refresh the errata list. 630 Author's Address 632 Tim Bray (editor) 633 Textuality 635 EMail: tbray@textuality.com