Explore BrainMass

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

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 :

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.