Network Working Group F. Yergeau Internet Draft G. Nicol G. Adams Expires 20 February 1996 M. Duerst 15 August 1995 Internationalization of the Hypertext Markup Language Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Please send comments to the HTML working group (HTML-WG) of the Internet Engineering Task Force (IETF) at . Discussions of the group are archived at URL: http://www.acl.lanl.gov/HTML_WG/archives.html. Abstract The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. Up to the present time, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded charac- ter set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other lan- guages, using other coded character sets or character encodings, through various ad hoc extensions to the language. This document is meant to address the issue of the internationaliza- tion of HTML by extending the specification of HTML 2.0 and giving Expires 20 February 1996 [Page 1] Internet Draft HTML internationalization 15 August 1995 additional recommendations for proper internationalisation support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use in all languages of the world. The "text/html; version=2.x" Internet Media Type [RFC1590] and MIME Content Type [RFC1521] is defined by this specification, taken together with the HTML 2.0 specification [HTML-2]. Table of contents 1. Introduction .................................................. 2 1.1. Scope ...................................................... 3 1.2. Conformance ................................................ 3 2. The document character set ..................................... 5 2.1. Reference processing model ................................. 5 2.2. The HTML 2.x document character set ........................ 7 2.3. Undisplayable characters ................................... 8 3. Language tags .................................................. 8 4. Additional entities and elements ...............................10 4.1. Full Latin-1 entity set ....................................10 4.2. Date, time, measures and monetary amounts ..................10 4.3. Entities and elements for language-dependent presentation ..12 5. Forms ..........................................................15 5.1. DTD additions ..............................................15 5.2. Form submission ............................................17 6. Miscellaneous ..................................................17 7. HTML public text ...............................................18 7.1. HTML DTD ...................................................18 7.2. SGML declaration for HTML ..................................34 7.3. Entity sets ................................................36 7.3.1. ISO Latin 1 character entity set .......................36 7.3.2. BIDI entity set ........................................39 Bibliography ......................................................39 Authors' Addresses ................................................41 1. Introduction The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. Up to the present time, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded charac- ter set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other lan- guages, using other coded character sets or character encodings, through various ad hoc extensions to the language [TAKADA]. Expires 20 February 1996 [Page 2] Internet Draft HTML internationalization 15 August 1995 This document is meant to address the issue of the internationaliza- tion of HTML by extending the specification of HTML 2.0 and giving additional recommendations for proper internationalisation support. It is in good part based on a paper by one of the authors on multi- lingualism on the WWW [NICOL]. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use in all languages of the world. The specific issues addressed are the SGML document character set to be used for HTML, the proper treatment of the charset parameter asso- ciated with the "text/html" content type and the specification of language tags and additional entities. 1.1 Scope HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. This specification extends the capabilities of HTML 2.0 (RFC xxx), primarily by removing the restriction to the ISO-8859-1 coded character set [ISO-8859-1]. Together with the HTML 2.0 specification, it defines a new version of HTML to be known as "HTML 2.x". HTML is an application of ISO Standard 8879:1986, Information Pro- cessing Text and Office Systems -- Standard Generalized Markup Lan- guage (SGML) [ISO-8879]. The HTML Document Type Definition (DTD) is a formal definition of the HTML syntax in terms of SGML. This specifi- cation amends the DTD of HTML 2.0 in order to make it applicable to documents encompassing a character repertoire much larger than that of ISO-8859-1, while still remaining SGML conformant. Together with the HTML 2.0, specification, this specification also defines HTML as an Internet Media Type [RFC1590] and MIME Content Type [RFC1521] called "text/html", or "text/html; version=2.x". As such, it defines the semantics of the HTML syntax and how that syntax should be interpreted by user agents. 1.2 Conformance This specification governs the syntax of HTML documents and aspects of the behavior of HTML user agents. 1.2.1 Documents A document is a conforming HTML document if: * It is a conforming SGML document, and it conforms to the HTML DTD Expires 20 February 1996 [Page 3] Internet Draft HTML internationalization 15 August 1995 (see 7.1, "HTML DTD"). * It conforms to the application conventions in this specification. For example, the value of the HREF attribute of the element must conform to the URI syntax. 1.2.2. User agents An HTML user agent conforms to this specification if: * It parses the characters of an HTML document into data characters and markup according to SGML [ISO-8879]. NOTE -- In the interest of robustness and extensibility, there are a number of widely deployed conventions for han- dling non-conforming documents. See section 4.2.1 of the HTML 2.0 specification [HTML-2], "Undeclared Markup Error Handling" for details. * It supports at least the ISO-8859-1 character encoding scheme and processes each character in the ISO Latin Alphabet No. 1 as speci- fied in section 6.1 of [HTML-2]. To ensure interoperability and proper support for at least ISO-8859-1 in an environment where character encoding schemes other than ISO-8859-1 are present, user agents must correctly interpret the charset parameter accompanying an HTML document received from the network. Furthermore, conforming user-agents are required to at least parse correctly numeric character references outside the range of ISO-8859-1, but within that of UCS-2. NOTE -- To support non-western writing systems, HTML user agents are encouraged to support `ISO-10646-UCS-2' or simi- lar character encoding schemes and as much of the character repertoire of [ISO-10646] as is practical. * It behaves identically for documents whose parsed token sequences are identical. For example, comments and the whitespace in tags disappear during tokenization, and hence they do not influence the behavior of con- forming user agents. * It allows the user to traverse (or at least attempt to traverse, resources permitting) all hyperlinks from elements in an HTML document. Expires 20 February 1996 [Page 4] Internet Draft HTML internationalization 15 August 1995 An HTML user agent is a level 2 user agent if, additionally: * It allows the user to express all form field values specified in an HTML document and to (attempt to) submit the values as requests to information services. 2. The document character set 2.1. Reference processing model This overview explains the reference processing model used for HTML 2.x, and in particular the SGML concept of a document character set. An actual implementation may widely differ in its internal workings from the model given below, but should behave as described to an out- side observer. Because there are various widely differing encodings of text, SGML does not directly address the question of how characters are encoded e.g. in a file. SGML views the characters as a single set (called a "character repertoire"), and a "code set" that assigns an integer number (known as "character number") to each character in the reper- toire. The document character set declaration defines what each of the character numbers represents [GOLD90, p. 451]. In most cases, an SGML DTD and all documents that refer to it have a single document character set, and all markup and data characters are part of this set. HTML, as an application of SGML, does not directly address the ques- tion of how characters are encoded as octets in external representa- tions such as files. This is deferred to mechanisms external to HTML, such as the HTTP protocol, or MIME for electronic mail. For the HTTP protocol [HTTP], the way characters are encoded is defined by the "charset" parameter[1] added to the "Content-Type" field of the header of an HTTP response. For example, to indicate that the transmitted document is encoded in the "JIS" encoding of Japanese [RFC1468], the header will contain the following line: Content-Type: text/html; charset=ISO-2022-JP _________________________ [1] The use of the keyword "charset" in MIME suggests that the corresponding parameter defines a character set in the terms used here. This is not true, the "charset" parameter actually specifies an encoding, i.e. the mapping of one (or several) character set(s) to octets. Expires 20 February 1996 [Page 5] Internet Draft HTML internationalization 15 August 1995 The default character set parameter in case of the HTTP protocol is ISO-8859-1 (the so-called "Latin-1" for Western European characters). The HTTP protocol also defines a mechanism for the client to define the character encodings it can accept. Clients and servers are strongly requested to use these mechanisms to assure correct trans- mission and interpretation of any document. Provisions that can be taken to help correct interpretation, even in cases where a server or client do not yet use these mechanisms, are described in section 6. Similarly, if HTML documents are transferred by electronic mail, the character encoding is defined by the "charset" parameter of the "Con- tent-Type" MIME header line [RFC1521]. In the case any other way of transferring and storing HTML documents are defined or become popular, it is advised that similar provisions should be made to clearly identify the character encoding used and/or to use a single/default encoding capable of representing the widest range of characters used in an international context. Whatever the external character encoding actually be, it is always translated to a representation of the document character set speci- fied in Section 2.2 before processing specific to SGML/HTML. The reference processing model can be depicted as follows: [resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display] [manager] [parser] ^ | | | +----------+ The decoder is responsible for decoding the external representation of the resource to a representation using the document character set. The entity manager, the parser, and the application deal only with characters of the document character set. A display-oriented part of the application or the display machinery itself may again convert characters represented in the document character set to some other representation more suitable for their purpose. In any case, the entity manager, the parser, and the application, as far as character semantics are concerned, are using the HTML 2.x document character set only. An actual implementation may choose to translate the document into some encoding of the document character set as described above. How- ever, the behaviour described by this reference processing model can be achieved otherwise, in particular by using scan-suppression tech- niques. This subject is well out of the scope of this specification, however, and the reader is invited to consult the SGML standard [ISO-8879] or a SGML handbook [BRYAN88] [GOLD90] [VANH90] [SQ91] for Expires 20 February 1996 [Page 6] Internet Draft HTML internationalization 15 August 1995 further information. The most important consequence of this reference processing model is that numeric character references are always resolved to the same characters, whatever the external encoding actually used. For an example, see Section 2.2. 2.2. The HTML 2.x document character set The document character set, in the SGML sense, of HTML 2.x is the Basic Multilingual Plane of ISO 10646:1993 [ISO-10646], also known as UCS-2. This is code-by-code identical with the Unicode standard [UNICODE]. The adoption of this document character set implies a change in the SGML declaration specified in the HTML 2.0 specifica- tion (section 9.5 of [HTML-2]). The change amounts to removing the two BASESET specifications and their accompanying DESCSET declara- tions, replacing them with the following declaration: BASESET "ISO Registration Number 176//CHARSET ISO/IEC 10646-1:1993 UCS-2 with implementation level 3 //ESC 2/5 2/15 4/5" DESCSET 0 9 UNUSED 9 2 9 11 2 UNUSED 13 1 13 14 18 UNUSED 32 95 32 127 1 UNUSED 128 32 UNUSED 160 65376 160 Making UCS-2 the document character set does not create non- conformance of any expression, construct or document that is conform- ing to HTML 2.0. It does make conforming certain constructs that are not admissible in HTML 2.0. One consequence is that data characters outside the repertoire of ISO-8859-1, but within that of UCS-2 become valid SGML characters. Another is that the upper limit of the range of numeric character references is extended from 255 to 65533[2] ; thus, И is a valid reference to a "CYRILLIC CAPITAL LETTER I". [ERCS] is a good source of information on Unicode and SGML, although its scope and technical content differ greatly from this _________________________ [2] 65533 (FFFD hexadecimal) is the last valid char- acter in UCS-2. 65534 (FFFE hexadecimal) is unassigned and reserved as the byte-swapped version of ZERO WIDTH NON-BREAKING SPACE for byte-sex detection purposes. 65535 (FFFF hexadecimal) is unassigned. Expires 20 February 1996 [Page 7] Internet Draft HTML internationalization 15 August 1995 specification. ISO 10646-1:1993 is the most encompassing character set currently existing, and there is no other character set that could take its place as the document character set for HTML 2.x. Also, it is expected that with future extensions of ISO 10646, this specification may also be extended. If nevertheless for a specific application there is a need to use characters outside this standard, this should be done by avoiding any conflicts with present or future versions of ISO 10646, i.e. by assigning these characters to a private zone. Also, it should be borne in mind that such a use will be highly unportable; in many cases, it may be better to use inline bitmaps. 2.3. Undisplayable characters With the document character set being the full ISO 10646 BMP, the possibility that a character cannot be displayed due to lack of appropriate resources (fonts) cannot be avoided. Because there are many different things that can be done in such a case, this document does not recommend any specific behaviour. Depending on the implemen- tation, this may also be handled by the underlaying display system and not the application itself. The following considerations, how- ever, may be of help: - A clearly visible, but unobtrusive behaviour should be preferred. Some documents may contain many characters that cannot be renden- dered, and so showing an alert for each of them is not the right thing to do. - In case a numeric representation of the missing character is given, its hexadecimal (not decimal) form is to be preferred, because this form is used in character set standards [ERCS]. 3. Language tags Language tags can be used to control rendering of a marked up docu- ment in various ways: character disambiguation, in cases where the character encoding is not sufficient to resolve to a specific glyph; quotation marks; hyphenation; ligatures; spacing; voice synthesis; etc. Independently of rendering issues, language markup is useful as content markup for purposes such as classification and searching. The language attribute, LANG, takes as its value a language tag that identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. The syntax and registry of HTML language tags is the same as that Expires 20 February 1996 [Page 8] Internet Draft HTML internationalization 15 August 1995 defined by RFC 1766 [RFC1766]. In summary, a language tag is composed of one or more parts: A primary language tag and a possibly empty series of subtags: language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Whitespace is not allowed within the tag and all tags are case- insensitive. The namespace of language tags is administered by the IANA. Example tags include: en, en-US, en-cockney, i-cherokee, x-pig-latin Two-letter primary-tags are reserved for ISO 639 language abbrevia- tions [ISO-639], and three-letter primary-tags for the language abbreviations of ISO CD 639-2 [ISO-CD-639-2] (the latter is in addi- tion to the requirements of RFC 1766). Any two-letter initial subtag is an ISO 3166 country code [ISO-3166]. In the context of HTML, a language tag is not to be interpreted as a single token, as per RFC 1766, but as a hierarchy. For example, a user agent that adjusts rendering according to language should con- sider that it has a match when a language tag in a style sheet entry matches the initial portion of the language tag of an element. An exact match should be preferred. This interpretation allows an ele- ment marked up as, for instance, "en-US" to trigger styles corre- sponding to, in order of preference, US-English ("en-US") or 'plain' or 'international' English ("en"). NOTE -- using the language tag as a hierarchy does not imply that all languages with a common prefix will be understood by those fluent in one or more of those lan- guages; it simply allows the user to request this commonal- ity when it is true for that user. Since any text can logically be assigned a language, almost all HTML elements admit the LANG attribute. The DTD reflects this. It is also intended that any new element introduced in later versions of HTML will admit the LANG attribute, unless there is a good reason not to do so. For the cases where a word or phrase differs only by language from the surrounding text, an element is needed as a container. This ele- ment is called LANG, and admits the LANG attribute. The rendering of elements is meant to be controlled (in part) by the LANG attribute. Specific user preferences set within the browser Expires 20 February 1996 [Page 9] Internet Draft HTML internationalization 15 August 1995 should override the value of the LANG attribute, which in turn over- rides the value specified by the LANG attribute of any enclosing ele- ment. If none of these are set, a suitable default, perhaps con- trolled by the user's locale, should be used to control rendering. 4. Additional entities and elements 4.1. Full Latin-1 entity set According to the suggestion of section 14 of [HTML-2], the set of Latin-1 entities is extended to cover the whole right part of ISO-8859-1. The names of the entities are taken from the appendices of [SGML]. A list is provided in section 7.3.1 of this specifica- tion. 4.2. Date, time, measures and monetary amounts One problem that faces the Web is that of data representation. Given the date "12/9/95", many people will think that this represents the 12th of September, 1995, while many others will think it represents December 9th. The same problem arises for many other data forms. It is desireable that the Web have a culture-neutral format for data, so that browsers can display the data in the most appropriate format for the end user. However, taking away all presentation choice from the publishers is also a bad idea, hence, some way of supplying override- able presentation hints is also desireable. A set of elements are proposed below to address the above problem. DATE This is used to store dates in such a way that formatting can be decided upon by the browser. It is desirable that the document author be able to provide the default format, with the end-user making the final decision. This format- ting is decided upon by the combination, of the CALENDAR and LANG attributes. The declaration of the DATE element is: If the CALENDAR attribute is not specified, the Gregorian calendar should be assumed, in which case, the format for the value of the VALUE attribute should be in yyyy-mm-dd format, as per ISO 8601:1988 [ISO-8601]. Expires 20 February 1996 [Page 10] Internet Draft HTML internationalization 15 August 1995 TIME Like the DATE element, the TIME element is used to store time such that it is independent of geographical location, and formatting. The declaration of the TIME element is: The contents of VALUE should be in hh:mm:ss.ss format. ZONE should contain a string representing the offset of the zone from GMT of the form "+HHMM" or "-HHMM". If omitted, Uni- versal Time (GMT) should be assumed. For example, Heading is preferred to

Heading

 --> ]]> Expires 20 February 1996 [Page 24] Internet Draft HTML internationalization 15 August 1995 " > #AttVal(Alt)" > Expires 20 February 1996 [Page 25] Internet Draft HTML internationalization 15 August 1995 Expires 20 February 1996 [Page 26] Internet Draft HTML internationalization 15 August 1995 ]]> ]]> Expires 20 February 1996 [Page 27] Internet Draft HTML internationalization 15 August 1995 ]]> Directory" > Menu" > Heading

Text ... is preferred to

Heading

Text ... --> ]]> Expires 20 February 1996 [Page 29] Internet Draft HTML internationalization 15 August 1995 Form:" %SDASUFF; "Form End." > Select #AttVal(Multiple)" > ]]> ]]> Expires 20 February 1996 [Page 32] Internet Draft HTML internationalization 15 August 1995 " > [Document is indexed/searchable.]"> Expires 20 February 1996 [Page 33] Internet Draft HTML internationalization 15 August 1995 ]]> 7.2. SGML Declaration for HTML 7.3. Entity sets 7.3.1. ISO Latin 1 Character Entity Set The following public text lists each of the characters specified in the Added Latin 1 entity set, along with its name, syntax for use, and description. This list is derived from ISO Standard 8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire entity set, and adds enti- ties for all missing characters in the right part of ISO-8859-1. Expires 20 February 1996 [Page 36] Internet Draft HTML internationalization 15 August 1995 Expires 20 February 1996 [Page 37] Internet Draft HTML internationalization 15 August 1995 Expires 20 February 1996 [Page 38] Internet Draft HTML internationalization 15 August 1995 7.3.2. BIDI Entity Set The following entity set is sufficient to support the full Unicode bidirectionnal algorithm. Bibliography [BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard Generalized Markup Language", Addison-Wesley, Reading, 1988. [ERCS] Extended Reference Concrete Syntax for SGML. [FILE-UPLOAD] E. Nebel and L. Masinter, "Form-based File Upload in HTML", Work in progress (draft-ietf-html- fileupload-02.txt), Xerox Corporation, April 1995. [GOLD90] C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed., Oxford University Press, 1990. [HTML-2] T. Berners-Lee and D. Connolly, "Hypertext Markup Lan- guage - 2.0", Work in progress (draft-ietf-html- spec-02.txt), MIT/W3C, May 1995. [HTTP] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen, "Hypertext Transfer Protocol - HTTP/1.0", Work in progress (draft-ietf-http-v10-spec-00.ps), MIT, UC Irvine, CERN, March 1995. [ISO-639] ISO 639:1988. Codes pour la reprsentation des noms de Expires 20 February 1996 [Page 39] Internet Draft HTML internationalization 15 August 1995 langue. Technical content in [ISO-CD-639-2] ISO CD 639-2:1992. Technical content in [ISO-1000] ISO 1000:1992. Units SI et recommandations pour l'emploi de leurs multiples et de certaines autres units. [ISO-3166] ISO 3166:1993. Codes pour la reprsentation des noms de pays. [ISO-4217] ISO 4217:1990. Codes pour la reprsentation des mon- naies et types des fonds. [ISO-8601] ISO 8601:1988. lments de donnes et formats d'change -- change d'information -- Reprsentation de la date et de l'heure. [ISO-8859-1] ISO 8859-1:1987. International Standard -- Informa- tion Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1. [ISO-8879] ISO 8879:1986. International Standard -- Information Processing -- Text and Office Systems -- Standard Gen- eralized Markup Language (SGML). [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Infor- mation technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [NICOL] G.T. Nicol, "The Multilingual World Wide Web", Elec- tronic Book Technologies, 1995, [RFC1468] J. Murai, M. Crispin and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, Keio University, Panda Programming, June 1993. [RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Inter- net Mail Extensions) Part One: Mechanisms for Specify- ing and Describing the Format of Internet Message Bod- ies", RFC 1521, Bellcore, Innosoft, September 1993. [RFC1590] J. Postel, "Media Type Registration Procedure", RFC 1590, USC/ISI, March 1994. Expires 20 February 1996 [Page 40] Internet Draft HTML internationalization 15 August 1995 [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, October 1994. [RFC1766] H. Alverstrand, "Tags for the Identification of Lan- guages", RFC 1766, UNINETT, March 1995. [SQ91] SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc., 1991. [TAKADA] Toshihiro Takada, "Multilingual Information Exchange through the World-Wide Web", Computer Networks and ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241. [TEI] TEI Guidelines for Electronic Text Encoding and Inter- change. [UNICODE] The Unicode Consortium, "The Unicode Standard -- Worldwide Character Encoding -- Version 1.0", Addison- Wesley, Volume 1, 1991, Volume 2, 1992. The BIDI algorithm is in appendix A of volume 1, with correc- tions in appendix D of volume 2. [VANH90] E. van Hervijnen, "Practical SGML", Kluwer Academicq Publishers Group, Norwell and Dordrecht, 1990. Authors' Addresses Franois Yergeau Alis Technologies 3410, rue Griffith Montral QC H4T 1A7 Canada Tel: +1 (514) 738-9171 Fax: +1 (514) 342-0318 EMail: yergeau@alis.ca Gavin Thomas Nicol Electronic Book Technologies, Japan 1-29-9 Tsurumaki, Setagaya-ku, Tokyo Japan Tel + Fax: +81-3-3706-7351 EMail: gtn@ebt.com, gtn@twics.co.jp Expires 20 February 1996 [Page 41] Internet Draft HTML internationalization 15 August 1995 Glenn Adams Stonehand 118 Magazine Street Cambridge, MA 02139 U.S.A. Tel: +1 (617) 864-5524 Fax: +1 (617) 864-4965 EMail: glenn@stonehand.com Martin J. Duerst Multimedia-Laboratory Departement of Computer Science University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland Tel: +41 1 257 43 16 Fax: +41 1 363 00 35 E-mail: mduerst@ifi.unizh.ch Expires 20 February 1996 [Page 42]