pass subtypes of "image" that they do not specifically recognize to a
secure and robust general-purpose image viewing application, if such
an application is available.
NOTE: Using of a generic-purpose image viewing application this way
inherits the security problems of the most dangerous type supported
by the application.
4.3. Audio Media Type
A media type of "audio" indicates that the body contains audio data.
Although there is not yet a consensus on an "ideal" audio format for
use with computers, there is a pressing need for a format capable of
providing interoperable behavior.
RFC 2046 Media Types November 1996
The initial subtype of "basic" is specified to meet this requirement
by providing an absolutely minimal lowest common denominator audio
format. It is expected that richer formats for higher quality and/or
lower bandwidth audio will be defined by a later document.
The content of the "audio/basic" subtype is single channel audio
encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.
Unrecognized subtypes of "audio" should at a miniumum be treated as
"application/octet-stream". Implementations may optionally elect to
pass subtypes of "audio" that they do not specifically recognize to a
robust general-purpose audio playing application, if such an
application is available.
4.4. Video Media Type
A media type of "video" indicates that the body contains a time-
varying-picture image, possibly with color and coordinated sound.
The term 'video' is used in its most generic sense, rather than with
reference to any particular technology or format, and is not meant to
preclude subtypes such as animated drawings encoded compactly. The
subtype "mpeg" refers to video coded according to the MPEG standard
[MPEG].
Note that although in general this document strongly discourages the
mixing of multiple media in a single body, it is recognized that many
so-called video formats include a representation for synchronized
audio, and this is explicitly permitted for subtypes of "video".
Unrecognized subtypes of "video" should at a minumum be treated as
"application/octet-stream". Implementations may optionally elect to
pass subtypes of "video" that they do not specifically recognize to a
robust general-purpose video display application, if such an
application is available.
4.5. Application Media Type
The "application" media type is to be used for discrete data which do
not fit in any of the other categories, and particularly for data to
be processed by some type of application program. This is
information which must be processed by an application before it is
viewable or usable by a user. Expected uses for the "application"
media type include file transfer, spreadsheets, data for mail-based
scheduling systems, and languages for "active" (computational)
material. (The latter, in particular, can pose security problems
which must be understood by implementors, and are considered in
detail in the discussion of the "application/PostScript" media type.)
RFC 2046 Media Types November 1996
For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates. An
intelligent user agent would use this information to conduct a dialog
with the user, and might then send additional material based on that
dialog. More generally, there have been several "active" messaging
languages developed in which programs in a suitably specialized
language are transported to a remote location and automatically run
in the recipient's environment.
Such applications may be defined as subtypes of the "application"
media type. This document defines two subtypes:
octet-stream, and PostScript.
The subtype of "application" will often be either the name or include
part of the name of the application for which the data are intended.
This does not mean, however, that any application program name may be
used freely as a subtype of "application".
4.5.1. Octet-Stream Subtype
The "octet-stream" subtype is used to indicate that a body contains
=7= |