Explore BrainMass

Explore BrainMass

    RFC 2045 and RFC 2046 top-level media types and sub-types

    This content was COPIED from BrainMass.com - View the original, and get the already-completed solution here!

    On RFC 2045 and RFC 2046 name the various top-level media types and sub-types defined in it.
    List possible values for different types and sub-types.
    As well as the elements :

    © BrainMass Inc. brainmass.com February 24, 2021, 2:29 pm ad1c9bdddf

    Solution Preview


    On RFC 2045 and RFC 2046 name the various top-level media types and sub-types defined in it.


    The initial document RFC 2045 specifies the various headers used to describe the structure
    of MIME messages. The second document, RFC 2046, defines the general structure of the MIME
    media typing system and defines an initial set of media types.

    An initial set of seven top-level media types is defined in RFC 2046. Five of these are
    discrete types whose content is essentially opaque as far as MIME processing is concerned.
    The remaining two are composite types whose contents require additional handling by MIME

    The five discrete top-level media types are:

    (1) text -- textual information. The subtype "plain" in
    particular indicates plain text containing no
    formatting commands or directives of any sort. Plain
    text is intended to be displayed "as-is". No special
    software is required to get the full meaning of the
    text, aside from support for the indicated character
    set. Other 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 of "text" thus include any
    word processor format that can be read without
    resorting to software that understands the format. In
    particular, formats that employ embeddded binary
    formatting information are not considered directly
    readable. A very simple and portable subtype,
    "richtext", was defined in RFC 1341, with a further
    revision in RFC 1896 under the name "enriched".

    (2) image -- image data. "Image" requires a display device
    (such as a graphical display, a graphics printer, or a
    FAX machine) to view the information. An initial
    subtype is defined for the widely-used image format
    JPEG. . subtypes are defined for two widely-used image
    formats, jpeg and gif.

    (3) audio -- audio data. "Audio" requires an audio output
    device (such as a speaker or a telephone) to "display"
    the contents. An initial subtype "basic" is defined in
    this document.

    (4) video -- video data. "Video" requires the capability
    to display moving images, typically including
    specialized hardware and software. An initial subtype
    "mpeg" is defined in this document.

    (5) application -- some other kind of data, typically
    either uninterpreted binary data or information to be
    processed by an application. The 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. The "PostScript" subtype is also defined
    for the transport of PostScript material. Other
    expected uses for "application" include spreadsheets,
    data for mail-based scheduling systems, and languages
    for "active" (computational) messaging, and word
    processing formats that are not directly readable.
    Note that security considerations may exist for some
    types of application data, most notably
    "application/PostScript" and any form of active
    messaging. These issues are discussed later in this

    The two composite top-level media types are:

    (1) multipart -- data consisting of multiple entities of
    independent data types. Four subtypes are initially
    defined, including the basic "mixed" subtype specifying
    a generic mixed set of parts, "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 has a default type of "message/rfc822".

    (2) message -- an encapsulated message. A body of media
    type "message" is itself all or a portion of some kind
    of message object. Such objects may or may not in turn
    contain other entities. The "rfc822" subtype is used
    when the encapsulated content is itself an RFC 822
    message. The "partial" subtype is defined for partial
    RFC 822 messages, to permit the fragmented transmission
    of bodies that are thought to be too large to be passed
    through transport facilities in one piece. Another
    subtype, "external-body", is defined for specifying
    large bodies by reference to an external data source.

    It should be noted that the list of media type values given here may be augmented in time,
    via the mechanisms described above, and that the set of subtypes is expected to grow

    Q: List possible values for different types and sub-types.

    Experimental Media Type Values

    This set of top-level media types is intended to be substantially complete. It is expected that
    additions to the larger set of supported types can generally be accomplished by the creation of
    new subtypes of these initial types. In the future, more top-level types may be defined only by
    a standards-track extension to this standard. If another top-level type is to be used for any
    reason, it must be given a name starting with "X-" to indicate its non-standard status and to
    avoid a potential conflict with a future official name.

    A media type value beginning with the characters "X-" is a private
    value, to be used by consenting systems by mutual agreement. Any format without a rigorous and
    public definition must be named with an "X-" prefix, and publicly specified values shall never
    begin with "X-". (Older versions of the widely used Andrew system use the "X-BE2" name, so new
    systems should probably choose a different name.)

    In general, the use of "X-" top-level types is strongly discouraged. Implementors should
    invent subtypes of the existing types whenever possible. In many cases, a subtype of
    "application" will be more appropriate than a new top-level type.


    Q: As well as the elements : Content-Type, Content-Transfer-Encording, Charset

    The whereabout comes the Content-Type header field, Content-Transfer-Encoding and
    where do Charset fits into the overall picture.

    Content-Type & Content-Transfer-Encording

    RFC 2045 describes several mechanisms that combine to solve most
    of the problems faced previously by RFC 822, without introducing any
    serious incompatibilities with the existing world of RFC 822 mail.
    In particular, it describes:

    (1) A MIME-Version header field, which uses a version number
    to declare a message to be conformant with MIME and allows mail
    processing agents to distinguish between such messages and those

    Solution Summary

    top-level media types and sub-types are noted.