| MIME, Multipurpose Internet Mail Extensions |
|
|
Description | Glossary | RFCs | Publications | Obsolete RFCs |
| Type: | Data encapsulation. |
| Working groups |
822ext, Internet Message Extensions. avt, Audio/Video Transport. conneg, Content Negotiation. vpim, Voice Profile for Internet Mail. |
| Links: |
IANA: Message headers. IANA: Application types. IANA: Audio types. IANA: Image types. IANA: Message types. IANA: Model types. IANA: Multipart types. IANA: Text types. IANA: Video types. |
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:
- textual message bodies in character sets other than US-ASCII
- an extensible set of different formats for non-textual message bodies
- multi-part message bodies, and
- textual header information in character sets other than US-ASCII.
RFC 2046, pages 3 - 6:
In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data.
The five discrete top-level media types are:
- 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".
- 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.
- audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents.
- video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software.
- 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.
The two composite top-level media types are:
- 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
- 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.
RFC 2047, page 3:
Certain sequences of "ordinary" printable ASCII characters (known as "encoded-words") are reserved for use as encoded data. The syntax of encoded-words is such that they are unlikely to "accidentally" appear as normal text in message headers. Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears.
Generally, an "encoded-word" is a sequence of printable ASCII characters that begins with "=?", ends with "?=", and has two "?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method.
MIME header fields.
| Header field | References |
|---|---|
| Content-Alternative | RFC 4021 |
| Content-Base | RFC 4021 |
| Content-Disposition | RFC 2183, RFC 4021 |
| Content-Duration | RFC 4021 |
| Content-Type. | RFC 4021 |
| MIME-Version. | RFC 4021 |
MIME-Version.
Header field.
Identifies the MIME version to be used.
Syntax:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Content-Duration.
Header field.
This field specifies the time duration of the content in seconds as a 32 bit unsigned integer.
Syntax:
duration := "Content-Duration" ":" 1*10DIGIT
Content-Type.
Header field.
(RFC 2045)
This field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary
information that may be required for certain media types.
After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation.
The ordering of parameters is not significant.
In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data.
Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if
the user agent has no knowledge of the specific image format "xyz".
Such information can be used, for example, to decide whether or not to show a user the raw data
from an unrecognized subtype -- such an action might be reasonable for unrecognized
subtypes of text, but not for unrecognized subtypes of image or audio.
For this reason, registered subtypes of text, image, audio, and video should not contain embedded information that is really of a different type.
Such compound formats should be represented using the "multipart" or "application" types.
Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content.
The set of meaningful parameters depends on the media type and subtype.
Most parameters are associated with a single specific subtype.
However, a given top-level media type may define parameters which are applicable to any subtype of that type.
Parameters may be required by their defining content type or subtype or they may be optional.
MIME implementations must ignore any parameters whose names they do not recognize.
For example, the "charset" parameter is applicable to any subtype of "text", while
the "boundary" parameter is required for any subtype of the "multipart" media type.
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.
Syntax:
content := "Content-Type" ":" type "/" subtype *(";" parameter)
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.>
x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens of this form must be registered with IANA as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values
Application.
Type.
This media type is to be used for discrete data which does 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.
Audio.
Type.
The body contains audio data.
Image.
Media type.
(RFC 2046)
A media type of "image" indicates that the body contains an image.
The subtype names the specific image format.
These names are not case sensitive.
An initial subtype is "jpeg" for the JPEG format using JFIF encoding.
| Subtype | Description | Reference |
|---|---|---|
| cgm | Computer Graphics Metafile. | |
| fits | FITS, Flexible Image Transport System. | |
| g3fax | RFC 1494 | |
| gif | RFC 2045, RFC 2046 | |
| ief | Image Exchange Format. | RFC 1314 |
| jp2 | RFC 3745 | |
| jpeg | RFC 2045, RFC 2046 | |
| jpm | RFC 3745 | |
| jpx | RFC 3745 | |
| naplps | ||
| png | PNG, Portable Network Graphics. | RFC 2083. |
| prs.btif | ||
| prs.pti | ||
| t38 | RFC 3362 | |
| tiff | Tag Image File Format. | RFC 1528, RFC 3302, RFC 3949 |
| tiff-fx | Tag Image File Format Fax eXtended. | RFC 3949, RFC 3950 |
| vnd.cns.inf2 | ||
| vnd.djvu | DjVu. | |
| vnd.dwg | ||
| vnd.dxf | ||
| vnd.fastbidsheet | ||
| vnd.fpx | ||
| vnd.fst | ||
| vnd.fujixerox.edmics-mmr | ||
| vnd.fujixerox.edmics-rlc | ||
| vnd.globalgraphics.pgb | ||
| vnd.microsoft.icon | ||
| vnd.mix | ||
| vnd.ms-modi | ||
| vnd.net-fpx | ||
| vnd.sealed.png | ||
| vnd.sealedmedia.softseal.gif | ||
| vnd.sealedmedia.softseal.jpg | ||
| vnd.svf | ||
| vnd.wap.wbmp | ||
| vnd.xiff |
Message.
Media type.
(RFC 2046)
It is frequently desirable, in sending mail, to encapsulate another mail message.
A special media type, "message", is defined to facilitate this.
In particular, the "rfc822" subtype of "message" is used to encapsulate RFC 822 messages.
| Subtype | Description | Reference |
|---|---|---|
| CPIM | CPIM, Common Profile for Instant Messaging. | RFC 3862 |
| delivery-status | RFC 3464 | |
| disposition-notification | RFC 3798 | |
| example | RFC 4735 | |
| external-body | RFC 1873, RFC 2045, RFC 2046 | |
| global | RFC 5335 | |
| global-delivery-status | RFC 5337 | |
| global-disposition-notification | RFC 5337 | |
| global-headers | RFC 5337 | |
| http | HTTP, HyperText Transfer Protocol. | RFC 2616 |
| imdn+xml | RFC 5438 | |
| news | (obsolete). | RFC 1036 |
| partial | RFC 2045, RFC 2046 | |
| rfc822 | RFC 2045, RFC 2046 | |
| s-http | HTTP, HyperText Transfer Protocol. | RFC 2660 |
| sip | SIP, Session Initiation Protocol. | RFC 3261 |
| sipfrag | SIP, Session Initiation Protocol. | RFC 3420 |
| tracking-status | RFC 3886 | |
| vnd.si.simp | SIMP, Shady Internet Media Protocol. | http://www.shadyindustries.biz/specs/ssd/ssd2.txt |
Model. Media type.
| Subtype | Description | Reference |
|---|---|---|
| iges | ||
| mesh | RFC 2077 | |
| vnd.dwf | ||
| vnd.flatland.3dml | ||
| vnd.gdl | ||
| vnd.gs.gdl | ||
| vnd.gtw | ||
| vnd.mts | ||
| vnd.parasolid.transmit.binary | ||
| vnd.parasolid.transmit.text | ||
| vnd.vtu | ||
| vrml | RFC 2077 |
Multipart.
Media type.
(RFC 2046)
In the case of multipart entities, in which one or more different sets of data
are combined in a single body, a "multipart" media type field must appear in the entity's header.
The body must then contain one or more body parts, each preceded by a
boundary delimiter line, and the last one followed by a closing boundary delimiter line.
After its boundary delimiter line, each body part then consists of a header area, a blank line, and a body area.
Thus a body part is similar to an RFC 822 message in syntax, but different in meaning.
| Subtype | Description | Reference |
|---|---|---|
| alternative | RFC 1766, RFC 2045, RFC 2046 | |
| appledouble | RFC 1740 | |
| byteranges | RFC 2068 | |
| digest | RFC 2045, RFC 2046 | |
| encrypted | RFC 1847 | |
| form-data | RFC 1867, RFC 2388 | |
| header-set | ||
| mixed | RFC 2045, RFC 2046 | |
| parallel | RFC 2045, RFC 2046 | |
| related | RFC 1872, RFC 2112, RFC 2387 | |
| report | RFC 3462 | |
| signed | RFC 1847 | |
| voice-message | RFC 2423, RFC 3801 |
Text.
Media type.
This media type is intended for sending material which is principally textual in form.
A "charset" parameter may be used to indicate the
character set of the body text for "text" subtypes, notably including the
subtype "text/plain", which is a generic subtype for plain text.
Plain text does not provide for or allow formatting commands, font attribute specifications, processing
instructions, interpretation directives, or content markup.
Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks.
Plain text may allow the stacking of several characters in the same position in the text.
Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the
arbitrary mixing of text segments with opposite writing directions.
Beyond plain text, there are many formats for representing what might be known as "rich text".
An interesting characteristic of many such representations is that they are to some extent
readable even without the software that interprets them.
It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or
text represented in an unreadable form.
In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is
not reasonable to do so with most nontextual data.
Such formatted textual data should be represented using subtypes of "text".
Video.
Media type.
This media type 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.
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".
Content-Description.
Header field.
(RFC 2045)
The ability to associate some descriptive information with a given body is often desirable.
For example, it may be useful to mark an "image" body as "a picture of the Space Shuttle Endeavor."
Such text may be placed in the Content-Description header field.
This header field is always optional.
The description is presumed to be given in the US-ASCII character set, although the mechanism specified in
RFC 2047 may be used for non-US-ASCII Content-Description values.
Syntax:
description := "Content-Description" ":" *text
Content-Disposition.
Header field.
An optional header field that can be used to convey presentational information.
Syntax:
disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm)
disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive.
disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / parameter
filename-parm := "filename" "=" value
creation-date-parm := "creation-date" "=" quoted-date-time
modification-date-parm := "modification-date" "=" quoted-date-time
read-date-parm := "read-date" "=" quoted-date-time
size-parm := "size" "=" 1*DIGIT
quoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used.
Content-features.
Header field.
(RFC 2912) This header provides additional information about the message
content directly contained or indirectly referenced in the corresponding MIME message part.
Syntax:
optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter
Content-ID.
Header field.
(RFC 2045) In constructing a high-level user agent, it may be desirable to allow one body to make reference to another.
Accordingly, bodies may be labelled using the
"Content-ID" header field, which is syntactically identical to the "Message-ID" header field.
The Content-ID value may be used for uniquely
identifying MIME entities in several contexts, particularly for caching data referenced by the message/external-body mechanism.
Although the Content-ID header is generally optional,
its use is MANDATORY in implementations which generate data of the optional MIME media type "message/external-body".
That is, each message/external-body entity must have a Content-ID field to permit caching of such data.
It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative media type.
This is explained in the section of RFC 2046 dealing with multipart/alternative.
Syntax:
id := "Content-ID" ":" msg-id
Content-MD5.
Header field.
An optional header field which may be used to verify that the decoded data are the same data that were initially sent.
This header may also be placed in the encapsulated headers of an object of type message/external-body, to be
used to verify that the retreived and decoded data are the same data that were initially referenced.
Content-Transfer-Encoding.
Header field.
Describes how the data contents in a message are encoded for transmission.
(RFC 2045) Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format. Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally:
Syntax:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token
Message-Context.
Header field.
This header provides information about the context and presentation characteristics of a message.
A receiving user agent may use this information as a hint to optimally present the message.
Character Sets.
(RFC 2047) The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text.
A 'charset' can be
any of the character set names allowed in an MIME "charset" parameter of a
"text/plain" body part, or any character set name registered with IANA for use with the MIME text/plain content-type.
Some character sets use code-switching techniques to switch between "ASCII mode" and other modes.
If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of
ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'.
(This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.)
When there is a possibility of using more than one character set to represent the text in an
'encoded-word', and in the absence of private agreements between sender and recipients of
a message, it is recommended that members of the ISO-8859-* series be used in preference to other character sets.
RFCs:
[RFC 934] Proposed Standard for Message Encapsulation.
[RFC 1036] Standard for Interchange of USENET Messages.
[RFC 1049] A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES.
[RFC 1123] Requirements for Internet Hosts -- Application and Support.
[RFC 1154] Encoding Header Field for Internet Messages.
[RFC 1343] A User Agent Configuration Mechanism For Multimedia Mail Format Information.
[RFC 1344] Implications of MIME for Internet Mail Gateways.
[RFC 1428] Transition of Internet Mail from Just-Send-8 to 8 bit-SMTP/MIME.
[RFC 1524] A User Agent Configuration Mechanism For Multimedia Mail Format Information.
[RFC 1528] Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures.
[RFC 1554] ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP.
[RFC 1555] Hebrew Character Encoding for Internet Messages.
[RFC 1556] Handling of Bi-directional Texts in MIME.
[RFC 1557] Korean Character Encoding for Internet Messages.
[RFC 1740] MIME Encapsulation of Macintosh files - MacMIME.
[RFC 1741] MIME Content Type for BinHex Encoded Files.
[RFC 1767] MIME Encapsulation of EDI Objects.
[RFC 1806] Communicating Presentation Information in Internet Messages: The Content-Disposition Header.
[RFC 1844] Multimedia E-mail (MIME) User Agent checklist.
[RFC 1847] Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
[RFC 1848] MIME Object Security Services.
[RFC 1864] The Content-MD5 Header Field.
[RFC 1873] Message/External-Body Content-ID Access Type.
[RFC 1874] SGML Media Types.
[RFC 1895] The Application/CALS-1840 Content-type.
[RFC 1896] The text/enriched MIME Content-type.
[RFC 1947] Greek Character Encoding for Electronic Mail Messages.
[RFC 2015] MIME Security with Pretty Good Privacy (PGP).
[RFC 2017] Definition of the URL MIME External-Body Access-Type.
[RFC 2045] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
[RFC 2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
[RFC 2047] MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.
[RFC 2049] Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples.
[RFC 2076] Common Internet Message Headers.
[RFC 2077] The Model Primary Content Type for Multipurpose Internet Mail Extensions.
[RFC 2122] VEMMI URL Specification.
[RFC 2156] MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME.
[RFC 2157] Mapping between X.400 and RFC-822/MIME Message Bodies.
[RFC 2159] A MIME Body Part for FAX.
[RFC 2160] Carrying PostScript in X.400 and MIME.
[RFC 2161] A MIME Body Part for ODA.
[RFC 2183] Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field.
[RFC 2231] MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.
[RFC 2318] The text/css Media Type.
[RFC 2387] The MIME Multipart/Related Content-type.
[RFC 2388] Returning Values from Forms: multipart/form-data.
[RFC 2392] Content-ID and Message-ID Uniform Resource Locators.
[RFC 2423] VPIM Voice Message MIME Sub-type Registration.
[RFC 2425] A MIME Content-Type for Directory Information.
[RFC 2426] vCard MIME Directory Profile.
[RFC 2442] The Batch SMTP Media Type.
[RFC 2445] Internet Calendaring and Scheduling Core Object Specification (iCalendar).
[RFC 2447] iCalendar Message-Based Interoperability Protocol (iMIP).
[RFC 2480] Gateways and MIME Security Multiparts.
[RFC 2483] URI Resolution Services Necessary for URN Resolution.
[RFC 2503] MIME Types for Use with the ISO ILL Protocol.
[RFC 2557] MIME Encapsulation of Aggregate Documents, such as HTML (MHTML).
[RFC 2560] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.
[RFC 2585] Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.
[RFC 2586] The Audio/L16 MIME content type.
[RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1.
[RFC 2652] MIME Object Definitions for the Common Indexing Protocol (CIP).
[RFC 2660] The Secure HyperText Transfer Protocol.
[RFC 2822] Internet Message Format.
[RFC 2833] RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
[RFC 2854] The 'text/html' Media Type.
[RFC 2862] RTP Payload Format for Real-Time Pointers.
[RFC 2910] Internet Printing Protocol/1.1: Encoding and Transport.
[RFC 2912] Indicating Media Features for MIME Content.
[RFC 2913] MIME Content Types in Media Feature Expressions.
[RFC 2927] MIME Directory Profile for LDAP Schema.
[RFC 2935] Internet Open Trading Protocol (IOTP) HTTP Supplement.
[RFC 2957] The application/whoispp-query Content-Type.
[RFC 2958] The application/whoispp-response Content-type.
[RFC 3003] The audio/mpeg Media Type.
[RFC 3009] Registration of parityfec MIME types.
[RFC 3016] RTP Payload Format for MPEG-4 Audio/Visual Streams.
[RFC 3023] XML Media Types.
[RFC 3029] Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols.
[RFC 3047] RTP Payload Format for ITU-T Recommendation G.722.1.
[RFC 3073] Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration.
[RFC 3080] The Blocks Extensible Exchange Protocol Core.
[RFC 3119] A More Loss-Tolerant RTP Payload Format for MP3 Audio.
[RFC 3156] MIME Security with OpenPGP.
[RFC 3189] RTP Payload Format for DV (IEC 61834) Video.
[RFC 3190] RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio.
[RFC 3204] MIME media types for ISUP and QSIG Objects.
[RFC 3236] The 'application/xhtml+xml' Media Type.
[RFC 3240] Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration.
[RFC 3249] Implementers Guide for Facsimile Using Internet Mail.
[RFC 3267] Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs.
[RFC 3282] Content Language Headers.
[RFC 3297] Content Negotiation for Messaging Services based on Email.
[RFC 3302] Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration.
[RFC 3335] MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet.
[RFC 3362] Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration.
[RFC 3367] Common Name Resolution Protocol (CNRP).
[RFC 3389] Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN).
[RFC 3391] The MIME Application/Vnd.pwg-multiplexed Content-Type.
[RFC 3420] Internet Media Type message/sipfrag.
[RFC 3458] Message Context for Internet Mail.
[RFC 3459] Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter.
[RFC 3462] The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.
[RFC 3464] An Extensible Message Format for Delivery Status Notifications.
[RFC 3497] RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video.
[RFC 3555] MIME Type Registration of RTP Payload Formats.
[RFC 3557] RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding.
[RFC 3558] RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV).
[RFC 3625] The QCP File Format and Associated Media Types.
[RFC 3640] RTP Payload Format for Transport of MPEG-4 Elementary Streams.
[RFC 3676] The Text/Plain Format and DelSp Parameters.
[RFC 3680] A Session Initiation Protocol (SIP) Event Package for Registrations.
[RFC 3745] MIME Type Registrations for JPEG 2000 (ISO/IEC 15444).
[RFC 3778] The application/pdf Media Type.
[RFC 3798] Message Disposition Notification.
[RFC 3801] Voice Profile for Internet Mail - version 2 (VPIMv2).
[RFC 3802] Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration.
[RFC 3803] Content Duration MIME Header Definition.
[RFC 3823] MIME Media Type for the Systems Biology Markup Language (SBML).
[RFC 3830] MIKEY: Multimedia Internet KEYing.
[RFC 3839] MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files.
[RFC 3842] A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).
[RFC 3858] An Extensible Markup Language (XML) Based Format for Watcher Information.
[RFC 3862] Common Presence and Instant Messaging (CPIM): Message Format.
[RFC 3863] Presence Information Data Format (PIDF).
[RFC 3864] Registration Procedures for Message Header Fields.
[RFC 3870] application/rdf+xml Media Type Registration.
[RFC 3880] Call Processing Language (CPL): A Language for User Control of Internet Telephony Services.
[RFC 3886] An Extensible Message Format for Message Tracking Responses.
[RFC 3902] The "application/soap+xml" media type.
[RFC 3910] The SPIRITS (Services in PSTN requesting Internet Services) Protocol.
[RFC 3923] End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP).
[RFC 3938] Video-Message Message-Context.
[RFC 3950] Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration.
[RFC 3952] Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech.
[RFC 3984] RTP Payload Format for H.264 Video.
[RFC 3994] Indication of Message Composition for Instant Messaging.
[RFC 4021] Registration of Mail and MIME Header Fields.
[RFC 4027] Domain Name System Media Types.
[RFC 4040] RTP Payload Format for a 64 kbit/s Transparent Call.
[RFC 4047] MIME Sub-type Registrations for Flexible Image Transport System (FITS).
[RFC 4060] RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding.
[RFC 4102] Registration of the text/red MIME Sub-Type.
[RFC 4103] RTP Payload for Text Conversation.
[RFC 4130] MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2).
[RFC 4141] SMTP and MIME Extensions for Content Conversion.
[RFC 4155] The application/mbox Media Type.
[RFC 4175] RTP Payload Format for Uncompressed Video.
[RFC 4180] Common Format and MIME Type for Comma-Separated Values (CSV) Files.
[RFC 4194] The S Hexdump Format.
[RFC 4235] An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP).
[RFC 4249] Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components.
[RFC 4263] Media Subtype Registration for Media Type text/troff.
[RFC 4267] The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml.
[RFC 4287] The Atom Syndication Format.
[RFC 4288] Media Type Specifications and Registration Procedures.
[RFC 4289] Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
[RFC 4298] RTP Payload Format for BroadVoice Speech Codecs.
[RFC 4329] Scripting Media Types.
[RFC 4337] MIME Type Registration for MPEG-4.
[RFC 4348] Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec.
[RFC 4351] Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream.
[RFC 4352] RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec.
[RFC 4354] A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service.
[RFC 4374] The application/xv+xml Media Type.
[RFC 4393] MIME Type Registrations for 3GPP2 Multimedia Files.
[RFC 4396] RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text.
[RFC 4421] RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes.
[RFC 4425] RTP Payload Format for Video Codec 1 (VC-1).
[RFC 4463] A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks.
[RFC 4539] Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF).
[RFC 5147] URI Fragment Identifiers for the text/plain Media Type.
[RFC 5222] LoST: A Location-to-Service Translation Protocol.
[RFC 5322] Internet Message Format.
[RFC 5337] Internationalized Delivery Status and Disposition Notifications.
[RFC 5362] The Session Initiation Protocol (SIP) Pending Additions Event Package.
[RFC 5371] RTP Payload Format for JPEG 2000 Video Streams.
[RFC 5391] RTP Payload Format for ITU-T Recommendation G.711.1.
[RFC 5408] Identity-Based Encryption Architecture and Supporting Data Structures.
[RFC 5621] Message Body Handling in the Session Initiation Protocol (SIP).
[RFC 561] Standardizing Network Mail Headers.
[RFC 733] STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES.
[RFC 822] STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES.
[RFC 1341] MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies.
[RFC 1342] Representation of Non-ASCII Text in Internet Message Headers.
[RFC 1486] An Experiment in Remote Printing.
[RFC 1495] Mapping between X.400 and RFC-822 Message Bodies.
[RFC 1521] MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies.
[RFC 1522] MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text.
[RFC 1523] The text/enriched MIME Content-type.
[RFC 1544] The Content-MD5 Header Field.
[RFC 1563] The text/enriched MIME Content-type.
[RFC 1590] Media Type Registration Procedure.
[RFC 1766] Tags for the Identification of Languages.
[RFC 1820] Multimedia E-mail (MIME) User Agent Checklist.
[RFC 1866] Hypertext Markup Language - 2.0.
[RFC 1867] Form-based File Upload in HTML.
[RFC 1872] The MIME Multipart/Related Content-type.
[RFC 1892] The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.
[RFC 1894] An Extensible Message Format for Delivery Status Notifications.
[RFC 1911] Voice Profile for Internet Mail.
[RFC 2048] Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
[RFC 2110] MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML).
[RFC 2111] Content-ID and Message-ID Uniform Resource Locators.
[RFC 2112] The MIME Multipart/Related Content-type.
[RFC 2184] MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.
[RFC 2298] An Extensible Message Format for Message Disposition Notifications.
[RFC 2301] File Format for Internet Fax.
[RFC 2302] Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration.
[RFC 2376] XML Media Types.
[RFC 2421] Voice Profile for Internet Mail - version 2.
[RFC 2422] Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration.
[RFC 2424] Content Duration MIME Header Definition.
[RFC 2565] Internet Printing Protocol/1.0: Encoding and Transport.
[RFC 2646] The Text/Plain Format Parameter.
[RFC 2793] RTP Payload for Text Conversation.
[RFC 3250] Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration.
[RFC 3546] Transport Layer Security (TLS) Extensions.
|
|
Description | Glossary | RFCs | Publications | Obsolete RFCs |