Image/Jpeg
        indicates an image in JPEG format.

    Image/Gif
        indicates an image in GIF format.

Message
    indicates an encapsulated message.

    Message/Rfc822
        indicates that the body contains an encapsulated message, with
        the syntax of an RFC 822 message.

    Message/Partial
        indicates a partial message, allowing fragmented transmission
        of bodies too large to be passed through mail transport
        facilities.  Message/Partial indicates that the body contains
        a fragment of a larger message.

        Three parameters are required in a Content-Type field of type
        Message/Partial: The first, Id, is a unique identifier, as
        close to world-unique as possible, used to match the parts
        together.  The second, Number, an integer, is the part number
        indicating where this part fits into the sequence of
        fragments.  The third, Total, another integer, is the total
        number of parts. Total is required on the final part, and
        optional on earlier parts.

    Message/External-Body
        indicates that the actual body data are not included, but
        merely referenced.  In this case, the parameters describe a
        mechanism for accessing the external data.

        When a body or body part is of type Message/External-Body,
        it consists of a header, a blank line, and the message header
        for the encapsulated message.  If another blank line appears,
        this ends the message header for the encapsulated message.
        However, since the encapsulated message's body is itself
        external, it does not appear in the area that follows.  For
        example, consider this message:

            Content-type: message/external-body;
                          access-type=local-file;
                          name=/u/nsb/Me.gif

            Content-type: image/gif

            THIS IS NOT REALLY THE BODY!

        The area at the end, which constitutes a phantom body, is
        ignored for most external-body messages.  However, it may be
        used to contain auxiliary information for a
        "mail-server".

        The only parameter of Message/External腂ody that is always
        mandatory is Access-Type.  Its other parameters are mandatory
        or optional depending on the value of Access-Type.  The values
        defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,
        AFS, LOCAL-FILE, and MAIL-SERVER.  Except for values beginning
        with X-, other values must be registered with IANA.

        The standard also specifies additional parameters that are to
        be used in conjunction with the various access types.

        In addition to access-type specific parameters, the standard
        defines the following parameters which are optional for all
        access types:

            * The Expiration parameter is used to specify a date after
              which the existence of the external data is not
              guaranteed. 

            * The Size parameter is used to specify the size of the
              data.

Multipart

    indicates data consisting of multiple body parts; each having its
    own data type.  It is possible to tell where each body part begins
    and ends because each body part is preceded by a special string
    called an encapsulation boundary; the last body part is followed
    by a closing boundary.

    The boundary strings used are specified by a mandatory parameter
    called Boundary.  The encapsulation boundary is an end of line
    followed by two hyphens followed by the boundary parameter value
    of the Content腡ype header field.  The closing boundary is the
    same as the encapsulation boundary with the addition of two
    hyphens at the end of the line.

    The encapsulation boundary must not appear inside any of the
    encapsulated parts.  It is crucial that the composing user agent
    be able to choose and specify the unique boundary that will
    separate the body parts.  Encapsulation boundaries may be no
    longer than 70 characters, not counting the blank line and leading
    hyphens.

    Thus, a typical multipart Content-Type header field might look
    like:

        Content-Type: multipart/mixed; boundary=gc0y0pkb9ex

    This indicates a body consisting of several body parts, each
    having a structure syntactically identical to an RFC 822 message,
    except that the header area may be completely empty, and each part
    is preceded by the line

        --gc0y0pkb9ex

    The closing boundary following the last body part indicates that
    no further body parts will follow.  It is identical to the
    preceding encapsulation boundaries, with the addition of two more
    hyphens at the end of the line:

        --gc0y0pkb9ex--

    There is room for additional information prior to the first
    encapsulation boundary and following the final boundary.  These
    areas are often blank.  Anything appearing before the first or
    after the last boundary is ignored.

    As a simple example, the following multipart message has two
    parts, both plain text, one explicitly typed and one implicitly
    typed:

        From: Nathaniel Borenstein <nsb@bellcore.com>
        To: Ned Freed <ned@innosoft.com>
        Subject: Sample message
        MIME-Version: 1.0
        Content-type: multipart/mixed;
                      boundary="simple boundary"

        This is the preamble.  It is to be ignored, though it is a
        handy place for mail composers to include an explanatory note
        to non-MIME compliant readers.

        --simple boundary

        This is implicitly typed plain ASCII text.
        --simple boundary
        Content-type: text/plain; charset=us-ascii

        This is explicitly typed plain ASCII text.
        It DOES end with a line break.

        --simple boundary--
        This is the epilogue.  It is also to be ignored.

    The use of a Content-Type of multipart in a body part within
    another multipart entity is explicitly allowed.  In such cases,
    care must be taken to ensure that each nested multipart entity
    uses a different boundary delimiter.

    The use of the multipart Content-Type with only a single body part
    may be useful in certain contexts, and is explicitly permitted.

    Multipart/Mixed
        indicates multiple independent body parts to be viewed
        serially.

    Multipart/Alternative
        is syntactically identical to Multipart/Mixed.  Each part is
        an "alternative" version of the same information.  Mail
        readers should recognize that the content of the parts are
        interchangeable.  The mail reader should either choose the
        "best" type based on the user's environment and preferences,
        or offer the user the available alternatives.  Generally,
        choosing the best type means displaying only the last part
        that can be displayed.  This may be used, for example, to send
        mail in a fancy text format in such a way that it can easily
        be displayed anywhere:

            From:  Nathaniel Borenstein <nsb@bellcore.com>
            To: Ned Freed <ned@innosoft.com>
            Subject: Formatted text mail
            MIME-Version: 1.0
            Content-Type: multipart/alternative;
                          boundary=boundary42


            --boundary42
            Content-Type: text/plain; charset=us-ascii

            ...plain text version of message goes here...
            --boundary42
            Content-Type: text/richtext

            ... richtext version of same message goes here ...
            --boundary42
            Content-Type: text/x-whatever

            ... fanciest formatted version of same message goes here
            ...
            --boundary42--

        In this example, users whose mail system understood the
        text/x-whatever format would see only the fancy version,
        while other users would see only the richtext or plain text
        version, depending on the capabilities of their system.

        Some mail reading programs that recognize more than one of the
        formats will offer the user a choice of which format to view.
        This makes sense, for example, if mail includes both a nicely
        formatted image version and an easily edited text version.
        The point is that multiple versions of the same data are not
        automatically shown.  Either the user is shown the last
        recognized version or explicitly given the choice.

    Multipart/Parallel
        is syntactically identical to Multipart/Mixed.  However, in a
        parallel body, all of the body parts are intended to be
        presented simultaneously on hardware and software that are
        capable of doing so.  Composing agents should be aware that
        many mail readers will lack this capability and will show the
        parts serially in any event.

        Multipart/Parallel will likely be used for multimedia messages
        that combine such message types as text, audio and/or video.

    Multipart/Digest
        Indicates that each of the body parts is an RFC 822 mail
        message.  Multipart/Digest is syntactically identical to
        Multipart/Mixed, except that the default Content-Type value
        for a body part is changed from Text/Plain to Message/Rfc822.

Text
    The text Content-Type is for sending material that is principally
    textual in form.  It is the default Content-Type.  A Charset
    parameter may be used to indicate the character set of the text.
    The default Content-Type for Internet mail is
        text/plain; Charset=US-ASCII.

    The value of the Charset parameter is not case sensitive.
    Allowable values are US-ASCII, ISO-8859-1, ISO-8859-2, ... and
    ISO-8859-9. The default value for Charset is US-ASCII.

    Text/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.  Other subtypes
        should 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 future subtypes include any readable
        word processor format.

    Text/Richtext
        indicates a simple portable word processing format that is
        defined by the MIME standard.  It is a very small subset of
        SGML.  Mail readers that implement Richtext may implement only
        a subset of it.

        When a mail composing program is given a file in a word
        processing format to send and there is no standardized subtype
        for that format, then the message composing program may
        reformat the file into richtext format which will preserve
        more of the original formatting information than reformatting
        the file to plain ASCII.

Video
    indicates that the body contains a time-varying-picture image,
    possibly with color and coordinated sound.  The term Video is
    used very generically and does not refer to any particular
    technology or format.  It is not meant to preclude subtypes
    such as animated drawings encoded compactly.

    Video/Mpeg
        indicates video coded according to the MPEG standard.

x-TypeName
    This is any type name that begins with X-.  A Content-Type value
    beginning with X- is a private value, to be used by consenting
    mail systems by mutual agreement.  The standard specifies no
    subtypes.

No type may be specified without a subtype.