Network Working Group E. Levinson Internet Draft: MIME/SGML Accurate Information Systems, Inc. November 1, 1994 MIME Content-types for SGML Documents This draft document is being circulated for comment. Please send your comments to the authors or to the ietf-822 maillist . If consensus is reached this document may be submitted to the RFC editor as a Proposed Standard protocol specification for use with MIME. Status of this Memo This document is an Internet Draft; Internet Drafts are working documents of the Internet Engineering Task Force (IETF) its Areas, and Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. They 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". Please check the abstract listing in each Internet Draft directory for the current status of this or any other Internet Draft. Abstract This document specifies how a document written using the Standardized General Markup Language (SGML) is to be carried within a MIME message. MIME provides a flexible mechanism for structuring RFC 822 message bodies. Additional mechanisms are required to encapsulate SGML documents which can consist of multiple parts. The mechanisms specify how to label the SGML parts and how to represent the internal references between the files. In addition, this document specifies the requirements for conformance to the SGML Document Interchange Format (SDIF). Subtypes are proposed for the Multipart and Application content types to support SGML documents and their interchange format within MIME. SGML is one of a class of compound documents which consist of a number of a set of parts or files, some of which may contain references to other files in the set. Explicit indications of the bindings between the sender's file names and the MIME body parts are needed to re-bind the sender's file names to ones on the recipient's system. Further, the document may refer to host system commands, a security E. Levinson Expires May 1, 1995 [Page 1] Internet Draft MIME Types for SGML Documents hazard which must be controlled. 0 Changes since last issued Changed DTD to prolog in text and definition. Increased precision when referring to SGML language elements. Various changes to clarify meaning. 1 Introduction The Multipurpose Internet Mail Extensions (MIME) specification [RFC-MIME] does not provide for objects (content-types) that consist of many interelated body parts when arbitrary relationships exist between the object's body parts. This document provides structuring mechanisms for encapsulating objects or documents encoded with the Standard Generalized Markup Language (SGML) [ISO-SGML]. MIME based mail User Agents can be configured to display (and compose) many different message body content-types. The user agents invoke applications that correspond to each particular content-type. Existing MIME content-types consist of a single body part and mechanisms to convey a collection of body parts. Recently, MIME subtypes have been registered that consist of a few related body parts, e.g. Apple MacIntosh file objects. In each case the body part is an independent and atomic unit. That is not the case with document objects, here the documents consist of many body parts that refer to one another; body parts whose display, independent of other body parts, has no meaning. Consequently the entire set of body parts must be treated as a single unit, a capability not present in MIME today. The general mechanism used here may apply to other markup languages, e.g. troff and TeX. The issues of internal structure, security, and control must be addressed separately for each markup language. 1.1 SGML SGML is used in several communities to encode document structure and layout. A rigorous description of SGML is left to [ISO-SGML]. Appendix A of this document, which is unbelievably brief, contains a description of the SGML elements relevant to MIME encapsulation. The terms used in the present document attempt to be consistent with SGML terminology and usage. A complete SGML document consists of an SGML declaration, a prolog, and a document instance. The prolog contains the document type definition (DTD), a description of the class E. Levinson Expires May 1, 1995 [Page 2] Internet Draft MIME Types for SGML Documents of documents to which the document instance belongs. Subdocuments are defined by their own prolog (and DTD). The prolog may, recursively, refer to subdocuments each of which consists of a prolog and instance. The applications that process SGML documents may require these documents or subdocuments to have each part (declaration, prolog, or instance) be individual files or a single file. For a person or application to receive and display a complete SGML document the mail message must carry a precise definition for each of the SGML document parts. In the sender's environment the document parts may reference standard definitions or specific local files. Further, a DTD may reference other files, for example images and graphics. The identity of the document parts and the content of each file must be available to enable the recipient to transform the sender's file name references into an equivalent local reference and to instantiate the files locally. 1.2 SGML Document Interchange Format (SDIF) The SGML Document Interchange Format (SDIF) [ISO-SDIF] specifies the structure for a data stream which contains one or more SGML documents. SDIF is focused on transferring documents between sites and does not include a requirement that the documents be displayed as they are encountered. Users of mail based systems, however, expect to have each mail item in a multipart message displayed -- more precisely, ready for display -- when encountered. This document shows how to meet both the SDIF and display requirements. 1.3 Organization of this Memorandum First a model for transferring SGML documents is presented; the model defines the processing required and introduces the SGML content types and parameters. The ensuing section provides the formal definition of those content types. That is followed by a brief discussion of the use of the Content-ID field. The last two sections cover SDIF and security considerations. 2 A Model for MIME/SGML Four issues must be addressed for the recipient's user agent to display a complete SGML document: the various parts must be specified and file references on the sender's systems must be resolved to references on the receiver's system, similarly, command references must be resolved. Finally, an appropriate application, an unpacker, must be in control to unpack of the MIME body parts and present them to the display software. The controlling application is discussed first and then the document parts, file references, and E. Levinson Expires May 1, 1995 [Page 3] Internet Draft MIME Types for SGML Documents command references. 2.1 Invoking the SGML Parser Application MIME offers the possibility to add SGML capability to existing MIME-capable mail user agents. They achieve that flexibility by invoking an application process based upon the body part's content-type. That process receives the body part and displays it. The approach is satisfactory when each body part is an atomic entity but this is not the case with compound SGML documents; the display must be deferred until all the body parts are available to the application and the internal entity structure is usable. To accomplish this, a process is interposed between the SGML application and the MIME user agent. Working on behalf of the recipient, the process instantiates each body part as a file on the local system, adjusts the internal file name references, and provides the appropriate formatting applications for non-SGML data; this process is called, in accordance with [ISO-SDIF], the unpacker (the corresponding process for the sender is the packer). Once the files have been instantiated the SGML viewer application can be invoked. It is natural to think of the various document parts as elements of a multipart MIME message. Insuring they are processed by the unpacker requires a specific multipart subtype, SGML. A MIME user agent that cannot handle SGML documents can use multipart/mixed as the default. The remaining parts of this section describe the requirements for instantiating a compound SGML document on the recipient's system. The next subsection discusses the document parts and the following one considers other data, included in the document by reference. 2.2 Specifying the Document Parts Different implementations of SGML parsers use different methods for storing the SGML declaration, DTD, and document instance. Consequently, for transfer, they are sent as separate MIME body parts. The unpacker will find these parts and store them as the local application requires; the receiver may substitute the local default for a missing SGML declaration or DTD. An alternate solution would have been to require a single file, the concatenation of the declaration, DTD, and instance. That would often require transferring much more data than needed; often only the document instance is required. The SGML document parts are specified as parameters of the Multipart/SGML content-type. Thus a sender includes the E. Levinson Expires May 1, 1995 [Page 4] Internet Draft MIME Types for SGML Documents declaration, prolog, and instance as separate body parts, and indicates, as the parameter value, the file-token associated with that body part. If neither the SGML declaration nor prolog is specified the recipient is free to apply a local default. The following parameters are provided for each document or subdocument instance. sgml-parm := *( ";" sgml-part "=" sgml-part-spec) [ ";" "sgml-version" "=" iso-sgml-spec ] [ ";" "created-with" "=" ref-or-tok ] [ ";" "charset" "=" charset ] sgml-part := "instance" / "prolog" / "dtd" / "fosi" / extension-token sgml-part-spec := file-token / sgml-public / extension-token file-token := content-ID sgml-public := iso-sgml-spec := Sgml-parts specify the various parts of a complete document. File-tokens are discussed in the next section; they refers to body parts whose content-ID: field matches the file- token. Sgml-public are identifiers that represent well known files or entities; they are discussed in the next section. The two parameters, sgml-version and created-with, are provided for guidance to user agents. Sgml-version specifies the particular SGML standard to which the document conforms. A user agent can use this value to invoke the application appropriate to that version of the standard. In the absence of this parameter the receiver will assume the version to be ISO 8879-1986. The created-with parameter provides guidance in cases where inter-operability with respect to SGML may be a problem. In environments where user's maintain several SGML processors, this parameter can be used to invoke the appropriate implementation; it is provided solely to accommodate existing environments. The created-with parameter is likely to be deprecated. The charset parameter specifies the body part character set. If not specified, the default is us-ascii. 2.3 Resolving File References E. Levinson Expires May 1, 1995 [Page 5] Internet Draft MIME Types for SGML Documents The SGML prolog contains a Document Type Definition (DTD) which defines document parts (entities) that can be referenced for inclusion or interpolation. The entities point to files that can contain SGML coded text, text not to be interpreted, images, or other data. Within SGML there are two types of file reference entities, SYSTEM and PUBLIC. PUBLIC entities specify SGML document parts that are known to and resolvable by SGML viewers and editors. The SYSTEM identifiers refer to files in the local environment. In order for the recipient's SGML application to properly process the document, the file references must be resolvable in the recipient's environment. Conceptually, one must replace each of the sender's file references with a corresponding reference in the recipient's file system. There are two issues here. First, the sending user agent must identify, in an architecturally neutral form, the sender's file references. Second, the correspondence between the file identity (name) and MIME body part must be preserved. This document applies the principle of "sender makes right" to these issues and requires first, that the packer convert all file references into a unique token containing only US-ASCII characters. The sender also must insure that the corresponding body part header contains a Content-ID: field whose value is the file's token. Thus, the internal file name, now a token suitable for an 822 header, explicitly appears in the document and as a content-ID label of the corresponding MIME body part. When the receiver stores the body part in the recipient's file system it can convert the internal file references (tokens) into valid local references. 2.4 Processors for Non-SGML Data Non-SGML data requires the SGML application to invoke a processor to format the data for display. The correspondence between the entity (file name) that contains the data and the processor is contained in the type field of the SGML entity declaration. The type corresponds to an SGML notation declaration The notation declaration contains the operating system command string that invokes the processor. That is, the string in the notation declaration is an arbitrary command! There are two problems with this situation, the command may only be valid in the sender's environment and, even if it is valid in the recipient's, invoking that command is a security hazard. Therefore, this document requires that any type used in an SGML notation be an valid MIME content type (or an extension token) thus insuring the recipient's user agent knows how to invoke the local display software. The recipient's mail user agent just substitutes a local string for the string in the corresponding notation declaration. E. Levinson Expires May 1, 1995 [Page 6] Internet Draft MIME Types for SGML Documents 3 The SGML Subtypes A complete document may be a single instance in which all the other document parts are defined by existing standards or private agreements. It may also be a set of parts several of which must be included in the MIME message. Two SGML subtypes are defined, Application/SGML and Multipart/SGML. Both content types use the same parameters. The multipart subtype is considered first; it is the general case. The application subtype is a simplification for the case where the multipart would contain a single part. It is also used for SGML subdocument entities, that is, text with mark-up. 3.1 The Multipart/SGML Subtype An SGML document can be carried in a MIME message as a Multipart body of subtype SGML (Content-Type: Multipart/SGML). The content-type parameters specify each of the parts of the SGML document. Additional parameters specify the software that created the document and the applicable SGML standard. A complex document contains references to standard parts (PUBLIC entities) and other files (SYSTEM entities). For PUBLIC entities no corresponding body part need exist. Each SYSTEM entity, on the other hand, corresponds to a body part labelled with a Content-ID: header. Thus a complete SGML document can appear as the following MIME message. E. Levinson Expires May 1, 1995 [Page 7] Internet Draft MIME Types for SGML Documents Content-Type: Multipart/SGML; instance=9311141653.VHFradio@ryc.pa.nj.us; prolog=9310240942.radioDTD@ryc.pa.nj.us; boundary=tiger-lily --tiger-lily Content-type: Application/SGML Content-ID: 9311141653.VHFradio@ryc.pa.nj.us < ... an SGML instance > --tiger-lily Content-type: Image/gif Content-ID: 9312161426.figure1@ryc.pa.nj.us <-- binary GIF date --> --tiger-lily Content-type: Application/SGML Content-ID: 9310240942.radioDTD@ryc.pa.nj.us ] --tiger-lily-- 3.2 The Application/SGML Subtype Application/SGML is used when transferring a file containing text and mark-up as part of a Multipart/SGML message or as a SGML document contained in a single body part. application-subtype := ("octet-stream" *stream) / "postscript" / ("sgml" *sgml-parm) / extension-token The following example shows a MIME message with a content- type that specifies a prolog. Content-Type: application/SGML; prolog="-//XYZ-CORP//SUBDOC RFC2010 100401//EN" 3.3 Character Set Considerations Consistent with MIME defaults, SGML documents use, by default, the ASCII character set. For documents not in that character set, the charset= parameter of the Content-Type: E. Levinson Expires May 1, 1995 [Page 8] Internet Draft MIME Types for SGML Documents field specifies the actual character set. Note that the values of the charset parameter must be registered with IANA, or be a mutually agreed upon extension-token (i.e., charset=X-set). 4 The Content-ID Header Field The Content-ID: header field , defined in [RFC-MIME], is a globally unique identifier and provides the link between file references within the SGML document and the MIME body parts. It constitutes a unique file name token which represents the sender's file name to which the body part corresponds. The process that creates the Multipart/SGML body parts, generates a content-ID value value for each file referenced by the document's DTDs. The packer then uses the content-ID value to replace the file name in the corresponding SGML ENTITY statements. Conversion of those values into valid references in the receiver's file system occurs upon document storage or display. It is recommended that the content-ID value include the name used within the ENTITY statement; this will improve the ability to associate the sender's data with the receivers. 5 SDIF [ISO-SDIF] Data Streams SDIF is an interchange format standard for SGML documents [ISO-SDIF]. It defines a data stream that may contain several SGML documents. This section defines a Multipart subtype "SDIF" for an SDIF data stream that contains one or more SGML documents. Messages that conform to the SDIF subtype will conform to [ISO-SDIF]. Briefly, an SDIF data stream is a sequence of SGML documents and their subdocument and external entities (c.f. Appendix A). These external entities are defined in the DTD and are referred to via their SGML name elsewhere in the prolog or in the document instance. Names are not unique across documents and subdocuments. Their scope is the document or subdocument that defines it and the subdocuments contained therein until redefined in one of those subdocuments. To provide unique identities within the SDIF data stream, each document and subdocument is recursively examined, breadth first, for external entities; each entity is sequentially numbered and placed in the data stream in the order encountered. Then each SGML document or subdocument structure in the SDIF data stream lists the number of the first entity it contains. When encoded in MIME, SDIF sequence numbers need not be explicitly represented; they can be recovered by parsing the input. The content-ID serves the same purpose and the MIME user agent can use it directly. E. Levinson Expires May 1, 1995 [Page 9] Internet Draft MIME Types for SGML Documents An SDIF data stream is encoded within a MIME message as a Multipart/SDIF body part. It contains one to three body parts. The first and third body parts, are Multipart/Mixed and are labelled with a content description field whose value is related-documents-A and related-documents-B respectively. The second body part is either a Multipart/SGML or Application/SGML (mime/sgml, for convenience) A Multipart/Mixed body parts only contain mime/sgml body parts. The Multipart/SDIF content type has a character set parameter which specifies the character set used for SGML markup tokens through-out the data stream. There are five SDIF entity types: subdocument These can contain references to external entities as well as marked up text. text An external entity containing only marked up text. data An external entity containing non-SGML data, images, for example. public-text Corresponds to a PUBLIC external reference and contains a NULL message body. cross-reference Corresponds to a previously included external entity. This avoids duplicating material previously included. It contains a NULL message body. This document requires the referenced body part to have already appeared to enable the user agent to display the SGML documents as they are encountered. The subdocument and text SDIF entities become Application/SGML body parts and data entities which are encapsulated as the appropriate MIME content type, application/SGML, image/gif, etc. The public-text and cross-reference entities have null message bodies and are handled as parameters, public and cross-reference, of an Application/SDIF content type. The syntax is: E. Levinson Expires May 1, 1995 [Page 10] Internet Draft MIME Types for SGML Documents appl-subtype := / "sdif" sdif-param sdif-param := ";" "public" "=" / ";" "cross-reference" "=" <-- the enclosing Multipart/SDIF body part is taken as the root (level 1) for numbering body parts --> SDIF requires the entity name to accompany each entity in the data stream. When MIME is used to transfer SDIF data streams the entity name will be the value of the content-description field in each body part. SDIF does not distinguish among the parts of a document entity (declara- tion, prolog, and instance). However, when SGML documents are contained in a Multipart/SDIF message the document parts are sent as separate body parts; that is, as a Multipart/SGML body part. Finally, SDIF uses sequential numbers to uniquely identify each entity, called an entity-identifier in [ISO-SDIF]. To locate the position of the first external entity, a first-identifier is provided for each docu- ment or sub-document. These are not necessary when using the methods in this paper but can be derived. Within a Multipart/SDIF message each body part is numbered sequentially, starting at 1 with the first Application/SGML body part. Note that the only Multipart body part that can be present in a Multipart/SDIF message is Mulitpart/Alternative. That will resolve into a single body part and shall be treated as though it were a non-multipart body part. The subdocument, text and data enti- ties may, in fact, be Message/External body parts. With the numbering described the unpacker may build a table to translate body parts into SDIF. When encapsulated with MIME each document can be displayed individually. The SDIF stream is a sequence of Multipart/SGML body parts. 6 Security An SGML parser can be directed to invoke a local process, usually to format or display a graphical image. That capability presents an oppor- tunity for abuse. To understand the potential problems requires under- standing two SGML constructs, entity and notation statements, presented below. Capitalized items are literals, lowercase ones are tokens, and the special characters are markup escape sequences. The document text will refer to name which, in turn, will cause the application, type, represented by qstring to be invoked. Qstring could be "delete *.*". To eliminate potential problems the unpacker should accept only E. Levinson Expires May 1, 1995 [Page 11] Internet Draft MIME Types for SGML Documents registered MIME types and subtypes. The unpacker can then replace the qstring in the NOTATION statement with the appropriate string for the recipient's environment. They are already defined for MIME. Types in the message that are not defined can be replaced by a no-operation NOTA- TION statement. SGML also provides for sending non-interpreted data to the display dev- ice or typesetter. The security hazard presented is similar to that posed by the use of PostScript. Greater threats may be posed by more "powerful" display systems and typesetters. Unauthorized access to the recipient's system and resources may be possible. 7 References [ISO-SGML] ISO 8879:1988, Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML). [ISO-SDIF] ISO 9069:1988, Information Processing - SGML Support Facili- ties -- SGML Document Interchange Format (SDIF). [RFC-822] Crocker, D., Standard for the Format of ARPA Internet Text Messages, August 1982, University of Delaware, RFC 822. [RFC-HDRC] Moore, Keith, Representation of Non-Ascii Text in Internet Message Headers, June, 1992, RFC 1342 [RFC-MIME] Borenstein, N. and Freed, N., MIME (Mulitpurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, June 1992, RFC 1341. [US-ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. 8 Acknowledgements The author acknowledges Harald T. Alvestrand, UniNett, Andy Gelsey, CSC, Nathaniel Borenstein, First Virtual Holdings Incorporated, Einar Stef- ferud, Network Management Associates, Inc, John Klensin, MCI, and Erik Naggum, for their suggestions, explanations, and encouragement. No errors or faults in this document can be ascribed to them, those are mine. UNIX is a registered trademark of UNIX System Laboratories, Inc. 9 Author's Address Ed Levinson elevinson@accurate.com Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 0772 E. Levinson Expires May 1, 1995 [Page 12] Internet Draft MIME Types for SGML Documents Appendix A. SGML for IETFers This is a description of the elements of the Standard Generalized Markup Language (SGML) that are key to understanding the relationship between SGML and the Multipurpose Internet Mail Extensions (MIME). For the pur- poses of this discussion, and without doing too much damage to the SGML specification, an SGML document contains text, markup, and references to non-text document elements (graphics). For a complete and accurate description see ISO 8879, Information Processing - Text and office sys- tems - Standard Generalized Markup Language (SGML). An SGML document has the following structure (the parenthesized numbers refer to productions in ISO 8879) and is processed by an application called an SGML parser. Note that Internet style ABNF is used for nota- tion here, SGML uses a different style. sgml-doc ::= sgml-decl prolog doc-inst (2) sgml-sub-doc ::= dtd doc-inst (3) Sgml-decl defines the various elements and parameters of SGML. For example, the characters that introduce and end markup tags, "<" and ">" respectively will be used here, the maximum length of markup tags, etc.. The prolog defines the document structure, usually through an SGML con- struct called the document type definition (DTD). Most importantly for interchange considerations, the DTD contains references to external files, system commands, and text to be sent directly to a typesetter or printer. Doc-inst is the actual document instance or text; it also includes graphic elements, other text with or without markup, by reference to DTD elements. The remainder of this discussion focuses on two elements which a DTD references, entities and notations. They appear in the DTD and have the following format. entity ::= "" (101) e-text ::= q-string | data | b-text | external (105) data ::= ( "CDATA" | "SDATA" | "PI" ) q-string (106) external ::= ext-id [ ( "SUBDOC" | ( "NDATA" type ) ) ] (108) ext-id ::= ( "SYSTEM" q-string) | ( "PUBLIC" pub-id [q-string] ) (73) notation ::= "" (148) where name is a character string and the definition of b-text left to ISO 8879; for convenience q-string has been substituted for the SGML term parameter literal. Entities referred to via the SUBDOC keyword differ from SGML documents in that they only contain a DTD and a doc- inst. Using the above productions the following simple example entities demon- strate the important issues. Name and type are alphanumeric tokens and E. Levinson Expires May 1, 1995 [Page 13] Internet Draft MIME Types for SGML Documents q-string is a series of characters enclosed in double (or single) quote marks. (A) (B) (C) (D) (E) Form A refers to a well known or "public" name that the SGML parser is able to resolve; in the marked up text there will be a markup item that directs the parser to include the corresponding public file. Similarly, form B corresponds to a locally known file. Form C allows the markup text to refer to non-SGML data, an image for example, and the type parameter must match the type of a NOTATION element . The matching element's command parameter specifies the command which processes the file fname. Finally form E, processing instructions, specifies a string of characters to be sent directly to the output device. These examples give rise to the following issues when the document is transferred from one environment to another. A Is the public name known to the recipient? The recipient SGML parser may not know of the public file and this will be discovered when it processes the document. B What is the file name on the recipient system? There must be some process which binds the sender's file names to the recipient. C See B and D. D Direct use of the NOTATION form is a large security risk, an invi- tation to a Trojan Horse attack. The recipient must be protected from a sender invoking an arbitrary command on the recipient sys- tem. E Processing instructions permit the sender to manipulate the reci- pient output device. This is the same risk that exists for PostScript documents and is not addressed. Issues A through D are addressed in this document. E. Levinson Expires May 1, 1995 [Page 14] Internet Draft MIME Types for SGML Documents Appendix B. Content-Type registrations _________________________________ The Application/SGML Content-Type (1) MIME type name: Application (2) MIME subtype name: SGML (3) Required parameters: none (4) Optional parameters: declaration, prolog, instance, fosi, charset, SGML-version, created-with (5) Encoding considerations: may be encoded (6) Security considerations: none (7) Specification: This subtype is used for text marked with the Standard Generalized Markup Language [ISO SGML]. Body parts of this subtype within a Multipart/SGML body part will contain a Content-ID: field. _________________________________ The Application/SDIF Content-Type (1) Mime type name: Application (2) MIME subtype name: SDIF (3) Required parameters: one of public or cross-reference (4) Optional parameters: none (5) Encoding considerations: none (6) Security considerations: E. Levinson Expires May 1, 1995 [Page 15] Internet Draft MIME Types for SGML Documents (7) Specification: This subtype contains a NULL or empty message body. The value of the public parameter is an SGML PUBLIC entity identifier. The value of cross-reference is the body part identifier of a previ- ously occurring body part. _________________________________ The Multipart/SGML Content-Type (1) Mime type name: Multipart (2) MIME subtype name: SGML (3) Required parameters: boundary (4) Optional parameters: declaration, prolog, instance, fosi, charset, SGML- version, created-with (5) Encoding considerations: none (6) Security considerations: none (7) Specification: As specified in this document. _________________________________ The Multipart/SDIF Content-Type (1) Mime type name: Multipart (2) MIME subtype name: SDIF (3) Required parameters: boundary (4) Optional parameters: charset (5) Encoding considerations: none E. Levinson Expires May 1, 1995 [Page 16] Internet Draft MIME Types for SGML Documents (6) Security considerations: none (7) Specification: As specified in this document. E. Levinson Expires May 1, 1995 [Page 17]