The seven standard initial predefined Content-Types are detailed in
   the bulk of this document.  They are:

    text -- textual information.  The primary subtype,
         "plain", indicates plain (unformatted) text.  No
         special software is required to get the full
         meaning of the text, aside from support for the
         indicated character set.  Subtypes are to be used
         for enriched text in forms where application
         software may enhance the appearance of the text,
         but such software must not be required in order to
         get the general idea of the content.  Possible
         subtypes thus include any readable word processor




 
RFC 1521                          MIME                    September 1993


         format.  A very simple and portable subtype,
         richtext, was defined in RFC 1341, with a future
         revision expected.

    multipart -- data consisting of multiple parts of
         independent data types.  Four initial subtypes
         are defined, including the primary "mixed"
         subtype, "alternative" for representing the same
         data in multiple formats, "parallel" for parts
         intended to be viewed simultaneously, and "digest"
         for multipart entities in which each part is of
         type "message".

    message -- an encapsulated message.  A body of
         Content-Type "message" is itself all or part of a
         fully formatted RFC 822 conformant message which
         may contain its own different Content-Type header
         field.  The primary subtype is "rfc822".  The
         "partial" subtype is defined for partial messages,
         to permit the fragmented transmission of bodies
         that are thought to be too large to be passed
         through mail transport facilities.  Another
         subtype, "External-body", is defined for
         specifying large bodies by reference to an
         external data source.

    image -- image data.  Image requires a display device
         (such as a graphical display, a printer, or a FAX
         machine) to view the information.  Initial
         subtypes are defined for two widely-used image
         formats, jpeg and gif.

    audio -- audio data, with initial subtype "basic".
         Audio requires an audio output device (such as a
         speaker or a telephone) to "display" the contents.

    video -- video data.  Video requires the capability to
         display moving images, typically including
         specialized hardware and software.  The initial
         subtype is "mpeg".

    application -- some other kind of data, typically
         either uninterpreted binary data or information to
         be processed by a mail-based application.  The
         primary subtype, "octet-stream", is to be used in
         the case of uninterpreted binary data, in which
         case the simplest recommended action is to offer
         to write the information into a file for the user.




 
RFC 1521                          MIME                    September 1993


         An additional subtype, "PostScript", is defined
         for transporting PostScript documents in bodies.
         Other expected uses for "application" include
         spreadsheets, data for mail-based scheduling
         systems, and languages for "active"
         (computational) email.  (Note that active email
         and other application data may entail several
         security considerations, which are discussed later
         in this memo, particularly in the context of
         application/PostScript.)

   Default RFC 822 messages are typed by this protocol as plain text in
   the US-ASCII character set, which can be explicitly specified as
   "Content-type: text/plain; charset=us-ascii".  If no Content-Type is
   specified, this default is assumed.  In the presence of a MIME-
   Version header field, a receiving User Agent can also assume that
   plain US-ASCII text was the sender's intent.  In the absence of a
   MIME-Version specification, plain US-ASCII text must still be
   assumed, but the sender's intent might have been otherwise.

      RATIONALE: In the absence of any Content-Type header field or
      MIME-Version header field, it is impossible to be certain that a