|
|
|
|
MIME Media Types defined in the context of SIP Standardization
The purpose of this page is to list the MIME media types defined in SIP-related RFCs
as well as Internet Drafts in the RFC Editor Queue.
It also lists the MIME media types most commonly used with SIP, with references to a list of
RFCs in this very page.
The exhaustive list of MIME media types can be found at:
http://www.iana.org/assignments/media-types/
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
| plain | |
- |
charset, format, delsp |
RFC 2046 -
RFC 3676
|
|
| html | |
- |
charset |
RFC 2854 |
|
xml
xml-external-parsed-entity | |
-
- |
charset
charset |
RFC 3023 |
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
jpeg
gif | |
-
- |
-
- |
RFC 2046 |
|
jp2
jpm
jpx | |
-
-
- |
-
-
- |
RFC 3745 |
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
| basic | |
- |
- |
RFC 2046 |
|
| mpeg | |
- |
- |
RFC 3003 |
|
| DV | |
encode |
- |
RFC 3189 |
|
| 3gpp | |
- |
codecs |
RFC 3839 -
RFC 4281 |
|
| 3gpp2 | |
- |
codecs |
RFC 4393 -
RFC 4281 |
|
| ac3 | |
rate |
channels, ptime, maxptime |
RFC 4184 |
|
| eac3 | |
rate |
bitStreamConfig |
RFC 4598 |
|
AMR
AMR-WB | |
- |
octet-align, mode-set, mode-change-period, mode-change-capability, mode-change-neighbor,
maxptime, crc, robust-sorting, interleaving, ptime, channels, max-red |
RFC 4867 |
|
| amr-wb+ | |
- |
channels, interleaving, int-delay, ptime, maxptime |
RFC 4352 |
|
| EVRC | |
- |
ptime, maxptime, maxinterleave |
RFC 3558 |
| EVRC0 | |
- |
- |
|
| SMV | |
- |
ptime, maxptime, maxinterleave |
|
| SMV0 | |
- |
- |
|
|
| mp4 | |
- |
- |
RFC 4337 |
|
| clearmode | |
- |
ptime, maxptime |
RFC 4040 |
|
BV16
BV32 | |
-
- |
ptime, maxptime
ptime, maxptime |
RFC 4298 |
|
| dls | |
- |
dls-type |
RFC 4613 |
|
| rtp-midi | |
rate |
Non-extensible parameters, Extensible parameters |
RFC 4695 |
| asc | |
- |
- |
|
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
| mpeg | |
- |
- |
RFC 2046 |
|
| DV | |
encode |
audio |
RFC 3189 |
|
| mj2 | |
- |
- |
RFC 3745 |
|
| 3gpp | |
- |
codecs |
RFC 3839 -
RFC 4281 |
|
| 3gpp2 | |
- |
codecs |
RFC 4393 -
RFC 4281 |
|
| 3gpp-tt | |
rate, sver |
tx, ty, layer, tx3g, width, height, max-w, max-h |
RFC 4396 |
|
| h264 | |
- |
profile-level-id, max-mbps, max-fs, max-cpb, max-dpb, and max-br,
redundant-pic-cap, sprop-parameter-sets, parameter-add, packetization-mode, sprop-interleaving-depth,
sprop-deint-buf-req, deint-buf-cap, sprop-init-buf-time, sprop-max-don-diff, max-rcmd-nalu-size |
RFC 3984 |
|
| mp4 | |
- |
- |
RFC 4337 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
signed
encrypted | |
boundary, protocol, micalg
boundary, protocol |
-
- |
RFC 1847 |
|
mixed
alternative
digest
parallel | |
boundary
boundary
boundary
boundary |
-
-
-
- |
RFC 2046 |
|
| related | |
boundary, type |
start, start-info |
RFC 2387 |
|
|
|
|
|
|
|
|
|
|
|
| subtype name |
|
required parameters |
optional parameters |
reference(s) |
|
| sip | |
- |
version |
RFC 3261 |
|
| sipfrag | |
- |
version |
RFC 3420 |
|
| cpim | |
- |
- |
RFC 3862 |
|
rfc822
partial
external-body | |
-
id, number, total
access-type |
-
-
expiration, size, permission |
RFC 2046 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RFC 822 defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for:
| |
|
|
(1) textual message bodies in character sets other than
US-ASCII,
(2) an extensible set of different formats for non-textual
message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
| |
|
|
|
|
| |
| Up |
Status: Draft Standard -- updated by RFC2231 |
|
|
|
|
|
| |
| Up |
Status: Draft Standard -- updated by RFC3676, RFC3798 |
|
|
|
|
|
| |
| Up |
Status: Draft Standard -- updated by RFC2231 |
|
|
|
|
|
| |
| Up |
Status: Best Current Practice (BCP: 13) -- Obsoletes: 2048 |
|
|
|
|
|
| |
| Up |
Status: Best Current Practice (BCP: 13) -- Obsoletes: 2048 |
|
|
|
|
|
| |
| Up |
Status: Draft Standard |
|
|
|
|
|
| | | |
RFC1847
10/1995
(11 p.)
[html]
[pdf(2)] |
J. Galvin
S. Murphy
S. Crocker
N. Freed |
PEM |
| Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted |
|
This document defines a framework within which security services may
be applied to MIME body parts. MIME, an acronym for "Multipurpose
Internet Mail Extensions", defines the format of the contents of
Internet mail messages and provides for multi-part textual and non-textual
message bodies. The new content types are subtypes of
multipart: signed and encrypted. Each will contain two body parts:
one for the protected data and one for the control information
necessary to remove the protection. The type and contents of the
control information body parts are determined by the value of the
protocol parameter of the enclosing multipart/signed or
multipart/encrypted content type, which is required to be present.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC2077
01/1997
(13 p.)
[html]
[pdf(2)] |
S. Nelson
C. Parks |
- |
| The Model Primary Content Type for
Multipurpose Internet Mail Extensions |
|
The purpose of this memo is to propose an update to Internet RFC 2045
to include a new primary content-type to be known as "model". RFC 2045
describes mechanisms for specifying and describing the
format of Internet Message Bodies via content-type/subtype pairs. We
believe that "model" defines a fundamental type of content with
unique presentational, hardware, and processing aspects. Various
subtypes of this primary type are immediately anticipated but will be
covered under separate documents.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC2183
08/1997
(12 p.)
[html]
[pdf(2)] |
R. Troost
S. Dorner
K. Moore |
- |
| Communicating Presentation Information in
Internet Messages: The Content-Disposition Header Field |
|
This memo provides a mechanism whereby messages conforming to the
MIME specifications can convey presentational information. It specifies the
"Content-Disposition" header field, which is optional and valid for
any MIME entity ("message" or "body part"). Two values for this
header field are described in this memo; one for the ordinary linear
presentation of the body part, and another to facilitate the use of
mail to transfer files. It is expected that more values will be
defined in the future, and procedures are defined for extending this
set of values.
|
|
|
| |
| Up |
Status: Proposed Standard -- updated by RFC2231 |
|
|
|
| | | |
RFC2231
11/1997
(10 p.)
[html]
[pdf(2)] |
N. Freed
K. Moore |
- |
| MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations |
This memo defines extensions to the RFC 2045 media type and RFC 2183
disposition parameter value mechanisms to provide
(1) a means to specify parameter values in character sets
other than US-ASCII,
(2) to specify the language to be used should the value be
displayed, and
(3) a continuation mechanism for long parameter values to
avoid problems with header line wrapping.
This memo also defines an extension to the encoded words defined in
RFC 2047 to allow the specification of the language to be used for
display as well as the character set.
|
|
|
| |
| Up |
Status: Proposed Standard -- updates RFC2045, RFC2047, RFC2183 |
|
|
|
| | | |
RFC2311
03/1998
(37 p.)
[html]
[pdf(2)] |
S. Dusse
P. Hoffman
B. Ramsdell
L. Lundblade
L. Repka |
SMIME |
| S/MIME Version 2 Message Specification |
|
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging
applications: authentication, message integrity and non-repudiation
of origin (using digital signatures) and privacy and data security
(using encryption).
|
|
|
|
|
|
|
| | | |
RFC2387
08/1998
(10 p.)
[html]
[pdf(2)] |
E. Levinson |
MHTML |
| The MIME Multipart/Related Content-type |
|
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and provides
examples of its use.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC2506
03/1999
(12 p.)
[html]
[pdf(2)] |
K. Holtman
A. Mutz
T. Hardie |
CONNEG |
|
Media Feature Tag Registration Procedure |
Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server
platforms, and communities. This has created a need for media
feature descriptions and negotiation mechanisms in order to identify
and reconcile the form of information to the capabilities and
preferences of the parties involved.
Extensible media feature identification and negotiation mechanisms
require a common vocabulary in order to positively identify media
features. A registration process and authority for media features is
defined with the intent of sharing this vocabulary between
communicating parties. In addition, a URI tree is defined to enable
sharing of media feature definitions without registration.
This document defines a registration procedure which uses the
Internet Assigned Numbers Authority (IANA) as a central registry for
the media feature vocabulary.
|
|
|
| |
| Up |
Status: Best Current Practice |
|
|
|
|
| | | |
RFC2533
03/1999
(37 p.)
[html]
[pdf(2)] |
G. Klyne |
CONNEG |
|
A Syntax for Describing Media Feature Sets |
A number of Internet application protocols have a need to provide
content negotiation for the resources with which they interact [1].
A framework for such negotiation is described in [2], part of which
is a way to describe the range of media features which can be handled
by the sender, recipient or document transmission format of a
message. A format for a vocabulary of individual media features and
procedures for feature registration are presented in [3].
This document introduces and describes a syntax that can be used to
define feature sets which are formed from combinations and relations
involving individual media features. Such feature sets are used to
describe the media feature handling capabilities of message senders,
recipients and file formats.
An algorithm for feature set matching is also described here.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
| | | |
RFC2585
05/1999
(8 p.)
[html]
[pdf(2)] |
R. Housley
P. Hoffman |
PKIX |
| Internet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTP |
|
The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key
Infrastructure (PKI). This document specifies the conventions for
using the File Transfer Protocol (FTP) and the Hypertext Transfer
Protocol (HTTP) to obtain certificates and certificate revocation
lists (CRLs) from PKI repositories. Additional mechanisms addressing
PKIX operational requirements are specified in separate documents.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC2703
09/1999
(20 p.)
[html]
[pdf(2)] |
G. Klyne |
CONNEG |
|
Protocol-independent Content Negotiation Framework |
A number of Internet application protocols have a need to provide
content negotiation for the resources with which they interact. MIME
media types [1,2] provide a standard method for handling one major
axis of variation, but resources also vary in ways which cannot be
expressed using currently available MIME headers.
This memo sets out terminology, an abstract framework and goals for
protocol-independent content negotiation, and identifies some
technical issues which may need to be addressed.
The abstract framework does not attempt to specify the content
negotiation process, but gives an indication of the anticipated scope
and form of any such specification. The goals set out the desired
properties of a content negotiation mechanism.
|
|
|
|
|
|
|
| | | |
RFC2738
12/1999
(5 p.)
[html]
[pdf(2)] |
G. Klyne |
CONNEG |
|
Corrections to "A Syntax for Describing Media Feature Sets" |
In RFC 2533, "A Syntax for Describing Media Feature Sets", an
expression format is presented for describing media feature
capabilities using simple media feature tags.
This memo contains two corrections to that specification: one fixes
an error in the formal syntax specification, and the other fixes an
error in the rules for reducing feature comparison predicates.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
| | | |
RFC2854
06/2000
(8 p.)
[html]
[pdf(2)] |
D. Connolly
L. Masinter |
- |
| The 'text/html' Media Type |
|
This document summarizes the history of HTML development, and defines
the "text/html" MIME type by pointing to the relevant W3C
recommendations.
|
|
|
|
|
|
|
| | | |
RFC2913
09/2000
(9 p.)
[html]
[pdf(2)] |
G. Klyne |
CONNEG |
|
MIME Content Types in Media Feature Expressions |
In "A Syntax for Describing Media Feature Sets", an expression format
is presented for describing media feature capabilities using simple
media feature tags.
This memo defines a media feature tag whose value is a Multipurpose
Internet Mail Extensions (MIME) content type. This allows the
construction of feature expressions that take account of the MIME
content type of the corresponding data.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
| | | |
RFC2938
09/2000
(18 p.)
[html]
[pdf(2)] |
G. Klyne
L. Masinter |
CONNEG |
|
Identifying Composite Media Features |
In RFC 2533, an expression format is presented for describing media
feature capabilities as a combination of simple media feature tags.
This document describes an abbreviated format for a composite media
feature set, based upon a hash of the feature expression describing
that composite.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
| | | |
RFC2987
11/2000
(6 p.)
[html]
[pdf(2)] |
P. Hoffman |
- |
|
Registration of Charset and Languages Media Features Tags |
|
This document contains the registration for two media feature tags:
"charset" and "language". These media features allow specification
of character sets and human languages that can be understood by
devices and the devices' users. The templates in this document are
derived from RFC 2506.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
| | | |
RFC3003
11/2001
(5 p.)
[html]
[pdf(2)] |
M. Nilsson |
- |
|
The audio/mpeg Media Type |
|
The audio layers of the MPEG-1 and MPEG-2 standards are in frequent
use on the internet, but there is no uniform Multipurpose Internet
Mail Extension (MIME) type for these files. The intention of this
document is to define the media type audio/mpeg to refer to this kind
of contents.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC3023
01/2001
(39 p.)
[html]
[pdf(2)] |
M. Murata
S. St.Laurent
D. Kohn |
- |
| XML Media Types |
|
This document standardizes new media types for use in
exchanging network entities that are related to the Extensible Markup
Language (XML). It also standardizes a convention (using
the suffix '+xml') for naming media types outside of these types
when those media types represent XML MIME (Multipurpose Internet Mail
Extensions) entities. XML MIME entities are currently exchanged via
the HyperText Transfer Protocol on the World Wide Web, are an
integral part of the WebDAV protocol for remote web authoring, and
are expected to have utility in many domains.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC3236
01/2002
(8 p.)
[html]
[pdf(2)] |
M. Baker
P. Stark |
- |
| The 'application/xhtml+xml' Media Type |
|
This document defines the 'application/xhtml+xml' MIME media type for
XHTML based markup languages; it is not intended to obsolete any
previous IETF documents, in particular RFC 2854 which registers
'text/html'.
|
|
|
|
|
|
|
| | | |
RFC3625
09/2003
(15 p.)
[html]
[pdf(2)] |
R. Gellens
H. Garudadri |
- |
|
The QCP File Format and Media Types for Speech Data |
RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (High
Rate Speech Service Option 17 for Wideband Spread Spectrum
Communications Systems, also known as QCELP 13K vocoder) data, but
does not specify a storage format. Many implementations have been
using the "QCP" file format (named for its file extension) for
exchanging QCELP 13K data as well as Enhanced Variable Rate Coder
(EVRC) and Selectable Mode Vocoders (SMV) data. (For example,
Eudora(r), QuickTime(r), and cmda2000(r) handsets).
This document specifies the QCP file format and updates the
audio/qcelp media registration to specify this format for storage,
and registers the audio/evrc-qcp and audio/smv-qcp media types for
EVRC and SMV (respectively) data stored in this format.
|
|
|
|
|
|
|
| | | |
RFC3629
11/2003
(14 p.)
[html]
[pdf(2)] |
F. Yergeau |
- |
|
UTF-8, a transformation format of ISO 10646 |
|
ISO/IEC 10646-1 defines a large character set called the Universal
Character Set (UCS) which encompasses most of the world's writing
systems. The originally proposed encodings of the UCS, however, were
not compatible with many current applications and protocols, and this
has led to the development of UTF-8, the object of this memo. UTF-8
has the characteristic of preserving the full US-ASCII range,
providing compatibility with file systems, parsers and other software
that rely on US-ASCII values but are transparent to other values.
This memo obsoletes and replaces RFC 2279.
|
|
|
|
|
|
|
| | | |
RFC3676
02/2004
(20 p.)
[html]
[pdf(2)] |
R. Gellens |
- |
| The Text/Plain Format and DelSp Parameters |
|
This specification establishes two parameters (Format and DelSP) to
be used with the Text/Plain media type. In the presence of these
parameters, trailing whitespace is used to indicate flowed lines and
a canonical quote indicator is used to indicate quoted lines. This
results in an encoding which appears as normal Text/Plain in older
implementations, since it is in fact normal Text/Plain, yet provides
for superior wrapping/flowing, and quoting.
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC4281
11/2005
(12 p.)
[html]
[pdf(2)] |
R. Gellens
D. Singer
P. Frojdh |
- |
|
The Codecs Parameter for "Bucket" Media Types |
Several MIME type/subtype combinations exist that can contain
different media formats. A receiving agent thus needs to examine the
details of such media content to determine if the specific elements
can be rendered given an available set of codecs. Especially when
the end system has limited resources, or the connection to the end
system has limited bandwidth, it would be helpful to know from the
Content-Type alone if the content can be rendered.
This document adds a new parameter, "codecs", to various type/subtype
combinations to allow for unambiguous specification of the codecs
indicated by the media formats contained within.
By labeling content with the specific codecs indicated to render the
contained media, receiving systems can determine if the codecs are
supported by the end system, and if not, can take appropriate action
(such as rejecting the content, sending notification of the
situation, transcoding the content to a supported type, fetching and
installing the required codecs, further inspection to determine if it
will be sufficient to support a subset of the indicated codecs, etc.)
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
| | | |
RFC4613
09/2006
(6 p.)
[html]
[pdf(2)] |
P. Frojdh
U. Lindgren
M. Westerlund |
- |
|
Media Type Registrations for Downloadable Sounds
for Musical Instrument Digital Interface (MIDI) |
The present document seeks to register a media type for Downloadable
Sounds (DLSes). The DLS format is used to define instruments for
widely used wavetable synthesizers associated with the standards.
DLSes and their associated standards are
maintained and defined by two organizations, the Musical Instrument
Digital Interface (MIDI) Manufacturers Association (MMA) and the
Association of the Musical Electronics Industry (AMEI).
The media type defined here is needed to identify DLS files correctly
when they are served over HTTP, included in multi-part documents, or
used in other places where media types are used.
|
|
|
|
|
|
|
| | | |
RFC4723
12/2006
(8 p.)
[html]
[pdf(2)] |
T. Kosonen
T. White |
- |
|
Registration of Media Type audio/mobile-xmf |
|
The MIDI Manufacturers Association (MMA) and the Association of
Musical Electronics Industry (AMEI) have produced the Mobile XMF
standard, which was developed particularly for mobile MIDI
applications. Mobile XMF is a very compact media type providing
high-quality synthetic audio content for music downloading and
messaging applications that require MIME registration. This document
registers the media type audio/mobile-xmf.
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: Proposed Standard |
|
|
|
|
|
|
|
|
|
