This section presents each of the MIME headers supported by the MIME package with a focus on using the headers effectively. The section provides background reading and a quick reference rather than task lists or a complete specification of the headers. For step-by-step instructions, see Chapter 9, "Using the MIME Package," For the complete details on a specific header, see the RFC that defines the header.
The key to using MIME headers effectively is understanding how the headers describe the content of the body. Example 32 shows a simple MIME message containing nine headers and a part body that consists of a single line of data.
MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: very simple MIME message Content-ID: <part00909@roguewave.example> Content-Location: http://roguewave.example/simple.txt Content-Disposition: inline This is the body of the message. |
Each header contains a label, such as MIME-Version, and a value, such as 1.0. The first five header fields are specified by MIME in RFC 2045. The Content-Location header is specified in RFC 2557, and the Content-Disposition header is specified in RFC 1806. Each header in this example message is discussed in more detail below.
A MIME message must contain a header with information on the version of the MIME format that the message follows. The name of this header is -MIME-Version. The value of the header indicates the revision of the MIME specification the message follows. The MIME package supports MIME version 1.0, so the value of this header in Example 32 is 1.0. Although the MIME package allows any version value, the only value defined by the MIME specifications is 1.0.
The header is only required for a top-level MIME message. Nested parts within a multipart message need not include the MIME-Version header.
RFC 2045 defines the Mime-Version header in Section 4 (p. 8).
The Content-Type header declares the original file format of the part body. In Example 32, the Content-Type header contains the value text/plain and one parameter, charset=us-ascii.
A Content-Type header contains two values separated by a slash. These values are the media type and subtype of the Content-Type. In Example 32, the media type is text and the subtype is plain.
The media type specifies the kind of content in broad terms, while the subtype is more specific. For example, the media type text has common subtypes such as plain, html, and xml. In all three cases, the basic format of the document is text, and the document can be considered text for many purposes, such as deciding whether the document can be usefully opened within a text editor. The subtype provides more detailed information about the content. Although an HTML document can be displayed as plain text, rendering the document in a browser or opening the document in an HTML editor may be more useful.
The two-part value gives applications a way to determine the preferred handling of a document. If the application recognizes both the media type and subtype, the application can handle the content in exactly the way the sender intended. If the application only recognizes the media type, the application can still provide a reasonable fallback.
Depending on the media type or subtype, a Content-Type may require a parameter. For example, MIME allows text content types to include a parameter specifying the character set. The Content-Type header in Example 32 contains the parameter charset=us-ascii.
MIME defines five media types for discrete content: text, image, audio, video, and application. The message media type is defined for MIME parts that contain complete messages as content, such as an email digest.
For messages containing more than one MIME part, the format defines a media type of multipart. The requirements of the multipart content type are intimately connected with the body of the message. Section 10.2.2, "Multipart Bodies," discusses -multipart message bodies and content types.
A Content-Type header is optional. The MIME specification defines a part without a Content-Type header as text/plain; charset=us-ascii.
RFC 2045 defines the Content-Type header in section 5 (p. 10). RFC 2046 discusses specific Content-Type values.
Each MIME part may contain a header that specifies whether the part was processed for transfer and how the body of the message part is currently represented. The field name of this header is Content-Transfer-Encoding. In Example 32, the Content-Transfer-Encoding header contains the value 7bit.
The MIME specification defines five distinct transfer encodings. Two of these encodings, base64 and quoted-printable, indicate that the part body was processed for transmission, and is currently represented as 7-bit ASCII. The remaining three encodings, 7bit, 8bit, and binary, indicate that the body has not been processed for transmission, and that the message is currently represented as either 7-bit ASCII, 8-bit ASCII, or as raw binary data. MIME also allows applications to define and use nonstandard values for the Content-Transfer-Encoding of a message.
The body of a part defined with a given transfer encoding must actually match the format declared. A MIME part that contains other MIME parts may only have an encoding of 7bit, 8bit, or binary. Table 1 summarizes the transfer encodings defined by the MIME specification and the body format that each encoding specifies.
| Field Value | Character Set | Body format |
| base64 | 7-bit ASCII | Encoded into 7-bit ASCII. Lines typically less than 78 characters. CRLF sequence only occurs as a line break. |
| q-uoted-printable | 7-bit ASCII | Encoded into 7-bit ASCII. Lines typically less than 78 characters. CRLF sequence only occurs as a line break. |
| 7bit | 7-bit ASCII | Unencoded 7-bit ASCII. Lines no longer than 998 characters. CRLF sequence only occurs as a line break. |
| 8bit | 8-bit ASCII | Unencoded 8-bit ASCII. Lines no longer than 998 characters. CRLF sequence only occurs as a line break |
| binary | No restrictions | Any data acceptable. CRLF may or may not indicate a line break. |
If a MIME part is 7bit, the Content-Transfer-Encoding header is optional. MIME parts with any other transfer encoding must contain a Content-Transfer-Encoding header. If the MIME part is a multipart content type, the part should not have an encoding of base64 or quoted-printable.
For more details on base 64 encoding, see Section 10.3.2, "Base 64 Encoding." For more details on quoted-printable encoding, see Section 10.3.3, "Quoted-Printable Encoding."
RFC 2045 defines the Content-Transfer-Encoding header in section 6 (p. 14).
The Content-ID header associates a unique ID with a MIME part. In Example 32, the Content-ID header contains the value <part00909@roguewave.example>. A Content-ID header is designed to allow external references to a given MIME part. Therefore, the Content-ID provided must be world-unique.
The value of a Content-ID header has the format <xxxx@yyyy>. A MIME application typically creates a world-unique value by setting the right side of the value to indicate the system where the MIME part originated. The left side of the value generally contains a serial number, an indication of the date and time the message was generated, or both. Most applications use a combination of letters, numbers, and common punctuation (typically, period and hyphen) for the values of xxxx and yyyy, even though the specification technically allows a slightly larger character set.
Most MIME messages contain a single Content-ID header, at the top level of the message. If the Content-Type of the part is m-ultipart/alternative, the MIME specification recommends that each contained part have a unique Content-ID unless each part contains exactly the same information (see RFC 2046 for complete details).
RFC 2045 defines the Content-ID header in section 7 (p. 26).
The Content-Description header briefly describes the body the part contains. In Example 32, the Content-Description header contains the value very simple MIME message. This header is only a human-readable description, and does not otherwise affect the structure or content of the part.
RFC 2045 defines the Content-Description header in section 8 (p. 27).
The Content-Location header associates a URI with the part. In Example 32, the Content-Location header contains the value http://roguewave.example/simple.txt. Other parts in the message can reference the part using the value of the Content-Location header. The URI in the header is only used by other parts within the same message. Therefore, the URI need not be world-unique or indicate an actual resource on the Internet.
RFC 2557 defines the Content-Location header in section 4.2 (p. 7).
The Content-Disposition header indicates how an application should present the body. A value of inline indicates that the part body should be presented as part of the message. A value of attachment indicates that the part body should be presented as an attached file. In Example 32, the Content-Disposition header contains the value inline. The body should be presented as part of the message.
RFC 1806 defines the Content-Disposition header.
The headers end at the first blank line in the part. Everything after the first blank line in the part is content of the message, which the MIME specification refers to as the message body or part body.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.