2004/id/draft-levinson-sgml-02.txt



       Network Working Group                            E. Levinson
       Internet Draft: MIME/SGML               Accurate Information
       <draft-levinson-sgml-02.txt>                   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 <ietf-822@dimacs.rutgers.edu>.  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     := <An SGML PUBLIC identifier>

               iso-sgml-spec   := <The identifier of the SGML
                                   specification to which the
                                   document conforms, e.g.
                                   ISO 8879-1986>

       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

               <!DOCTYPE radio
                         PUBLIC -//USA-DOD//DTD DRAFT TEMPLATE 911201//EN"
                       [<!ENTITY figure1
                          SYSTEM "9312161426.figure1@ryc.pa.nj.us" NDATA gif
                          -- a reference to the file "figure1" --
                       >]

               --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"

               <! ... an SGML instance >

       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 := <existing> / "sdif" sdif-param

               sdif-param   := ";" "public" "="
                               <an SGML PUBLIC identifier>
                             / ";" "cross-reference" "="
                               <a previous MIME body part Content-ID>
                               <-- 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.

               <!ENTITY name SYSTEM file NDATA type>
               <!NOTATION type SYSTEM qstring>

       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   ::= "<!" "ENTITY" name e-text ">"              (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 ::=    "<!" "NOTATION" type ext-id ">"         (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.

               <!ENTITY name PUBLIC pname>                     (A)
               <!ENTITY name SYSTEM fname>                     (B)
               <!ENTITY name SYSTEM fname NDATA type>          (C)
               <!NOTATION type SYSTEM command>                 (D)
               <!ENTITY name PI q-string>                      (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
       <name> 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]
