multipart/alternative [RFC1521]

The multipart/alternative content type is used when the same information is presented in different body parts in different forms. The body parts are ordered by increasing complexity. For example, a message that consists of a heavily formatted Microsoft® Word 97 document might also be presented in Word 6.0 format, rich text format, and a plain text format. In this case the plain text would be presented as the first alternative body part. The rich text version would follow, then the Word 6.0, then the most complex, Word 97. Placing the plain text version first is the friendliest scheme for user agents (UAs) that are not compliant with Multipurpose Internet Mail Extensions (MIME), because they will see the recognizable version first. MIME-compliant UAs should present the most complex version that they can recognize or give the user a choice of which version to view. Content-ID values should be different for each part where there are different levels of complexity between parts. The content-ID of each part should be different from the content-ID of the overall multipart/alternative. That is, one content-ID value will refer to the multipart/alternative entity, while one or more other content-ID values will refer to the parts inside it.

multipart/byteranges [RFC2068]

The multipart/byteranges content type is defined as a part of the HTTP message protocol. It includes two or more parts, each with its own Content-Type and Content-Range fields. The parts are separated using a MIME boundary parameter. This allows for binary as well as 7-bit and 8-bit files to be sent as multiple parts with the lengths of the parts being specified in the header of each part. Note that while HTTP makes provisions for using MIME for HTTP documents, HTTP is not strictly MIME-compliant.

multipart/digest [RFC1521]

The multipart/digest content type is used to send collections of plain-text messages. This is accomplished in the same way as the multipart/mixed content-type, but each body part is expected to be of content-type: message/RFC 822.

multipart/form-data [RFC1867]

The multipart/form-data content type is intended to allow information providers to express file upload requests uniformly, and to provide a MIME-compatible representation for file upload responses.

multipart/mixed [RFC1521]

The multipart/mixed content type is used when the body parts are independent and need to be bundled in a particular order. When a UA does not recognize a multipart subtype, it will treat the message as multipart/mixed.

multipart/parallel [RFC1521]

The purpose of the multipart/parallel content type is to display all of the parts simultaneously on hardware and software that can do so. For instance, an image file can be displayed while a sound file is playing.

multipart/related [RFC2112]

The multipart/related content type is used for compound documents (that is, messages in which the separate body parts are intended to work together to provide the full meaning of the message). Additionally, multipart/related can be used to provide links to content not contained within the message. Multipart/related can be used for compound documents where the object is built progressively from pieces, starting with the 'root' body part as specified in the start parameter. If the start parameter is not specified, then the first body part is considered the starting point or 'root' body part. Multipart/related requires a type parameter. The type parameter specifies the content type of the first or 'root' part. Multipart/related processing takes precedence over content-disposition. Many MIME user agents do not recognize multipart/related and treat these messages as multipart/mixed. To allow for this, some UAs will include the technically unnecessary Content-Disposition header in multipart/related body parts. Content-Location and Content-Base headers are defined to resolve URL references to other body parts. Both headers are valid in any message or body part. They are valid for the content heading or message heading where they occur and for its content. The Content-Location and Content-Base headers apply to headers and body parts where they occur and do not have meaning in multipart headings. The Content-Base header gives a base for relative URIs occurring in other heading fields and in HTML documents that do not have any BASE element in its HTML code. Its value must be an absolute Uniform Resource Identifier (URI). The Content-Location header contains a URL that specifies the body of that body part. The URL may be relative to a URL specified in a Content-Base header. The following example shows how these headers are used:

multipart/report [RFC1892]

The multipart/report content type was defined for returning delivery status reports, with optional included messages. It is finding wider use in machine-to-machine communication. The multipart/report is used for Message Disposition Notification.

multipart/signed, multipart/encrypted [RFC1847]

The multipart/signed and multipart/encrypted content types provide a security framework for MIME parts. These headers do not define security protocols, but exist to carry the protected documents. Each multipart/signed or multipart/encrypted body part is carried as two related parts, one with the control information describing the protocol and one with the protected document. The multipart/signed content type specifies how to support authentication and integrity services using digital signature. The control information is carried in the second of the two required body parts. The multipart/encrypted content type specifies how to support confidentiality using encryption. The control information is carried in the first of the two required body parts.