Content-Type
The example in Sample MIME Message shows how MIME uses headers and multiple body parts. But the real power of MIME is in its ability to handle a wide variety of content types. Some encoding schemes are defined by MIME. An even broader range of possibilities is anticipated, and organizational elements are provided to handle the rich set of possibilities inherent in MIME. The "Content-Type:" header field is specified to organize media types. This allows the UA to present the body part to the user in its appropriate form, to engage the services of a tool that can process the body part, or to save the body part as a file for offline processing. The content type can be either "composite" or "discrete."
The two composite top-level media types are:
Multipart
Message
The five discrete top-level media types are:
Text
Image
Audio
Video
Application
Content-Type: application
Content-Type: application
The application content type allows for the transmission of application data or binary data, effectively allowing for specific handling of application data. The following application subtypes might be encountered:
application/cals-1840 [RFC1895]
application/marc [RFC2220]
application/news-message-id [RFC1036]
application/news-transmission [RFC1036]
application/octet-stream [RFC1521]
application/oda [RFC1521]
application/pgp-encrypted [RFC2015]
application/pgp-keys [RFC2015]
application/pgp-signature [RFC2015]
application/pkcs7-MIME [RFC2311]
application/pkcs7-signature [RFC2311]
application/pkcs10 [RFC2311]
application/postscript [RFC1521]
application/remote-printing [RFC1486]
application/sgml [RFC1874]
application/x400-bp [RFC1494]
Content-Type: audio
The audio content type allows standardized audio files to be included in messages.
audio/32kadpcm [RFC1911]
audio/basic [RFC1521]
Content-Type: image
Content-Type: image
The image content type allows standardized image files to be included in messages.
image/g3fax [RFC1494]
image/gif [RFC1521]
image/ief (Image Exchange Format) [RFC1314]
image/jpeg [RFC1521]
image/tiff (Tag Image File Format) [RFC2301]
Content-Type: message
The message content type allows messages to contain other messages or pointers to other messages.
message/delivery-status[RFC1894]
The message/delivery-status content type is defined for use in message delivery status notification, allowing automated information transmission.
message/disposition-notification-to[RFC2298]
The message/disposition-notification-to content type adds enhanced functionality to messaging. This works within the framework of the multipart/report content type.
message/external-body[RFC1521]
The message/external-body content type allows the contents of a message to be external to the message and only referenced in the message. The only required parameter of this content type is access-type, which can have values such as "FTP" and "LOCAL-ACCESS." If values are used that have not been registered with IANA, then they begin with "x-". Message/external-body parts must include a Content-ID header field with a unique identifier to reference the external data.
message/http[RFC2068]
The message/http content type is not strictly a MIME content type. Provisions are made in the definition of HTTP to allow it to be used over MIME transport mechanisms, but there must be a conversion between HTTP and MIME for strict MIME adherence.
message/partial [RFC1521]
The message/partial content type allows for large messages to be broken up into smaller messages. The full message can then be put back together by the UA. Only 7bit content-transfer-encoding is allowed for this content type. Three parameters are required:
id: a unique identifier used to match up the pieces.
number: an integer identifying which piece of the message this is.
total: an integer indicating the total number of parts the message has. This parameter is required only on the final fragment of the message, but should be used on all parts.
message/rfc822[RFC1521]
The message/rfc822 content type is used to enclose a complete message within a message. It is different from other MIME body parts in that it must be a fully formed RFC822 message, complete with headers.
Content-Type: multipart
Content-Type: multipart
Multi-part Content-Type headers identify multipart messages. They require that a subtype and other elements be included in the header.
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 Microsoft Word version 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 users with non-MIME-compliant UAs, because they will see the recognizable version first. The 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. It 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 used to send collections of plain-text messages. It is accomplished in the same way as the multipart/mixed content-type, but each body part is expected to be of content-type: message/rfc822.
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, those 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 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:
Content-Type: Multipart/related; boundary="boundary-content_example";
type=Text/HTML; start=example@example.com
;Content-Base header not allowed here
;since this is a multipart MIME object
--boundary-content_example
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID:
Content-Location: http://www.example.com/images/the.one
; This Content-Location must contain an absolute URL, since no base ; is valid here.
--boundary-content_example
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID:
Content-Location: the.one ; The Content-Base below applies to
; this relative URL
Content-Base: http://www.example.com/images/
--boundary-content_example--
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.
Content-Type: text
Content-Type: text
The text content type is used for message content that is primarily in human-readable text character format. The more complex text content types are defined and identified so that an appropriate tool can be used to display that body part.
text/enriched [RFC1896]
The text/enriched content type is intended to be simple enough to make multifont, formatted e-mail widely readable. It uses a very limited set of formatting commands that all begin with
text/html[RFC1866]
The text/html content type is an Internet Media Type as well as a MIME content type. Using HTML in MIME messages allows the full richness of Web pages to be available in e-mail.
text/plain[RFC1521]
The text/plain content type is the generic subtype for plain text. It is the default specified by RFC 822.
text/rfc822-headers[RFC1892]
The text/RFC822-headers content type provides a mechanism for an MTA to label and return only the RFC 822 headers of a failed message. Only the headers are returned, not the complete message. The returned headers are useful for identifying the failed message and for diagnosing delivery problems. All headers are to be returned, up to the blank line following the headers.
text/richtext[RFC1521]
The text/richtext content type has been made obsolete by text/enriched.
text/sgml[RFC1874]
The text/sgml content type is intended to be used when the contents of the SGML entity is intended to be read by a human and is in a readily comprehensible form — that is, the content can be easily discerned by Someone without SGML display software. Each record in the SGML entity, delimited by record start (RS) and record end (RE) codes, must correspond to a line in the text/SGML body part
Content-Type: video
Content-Type: video
The video content type allows standardized video files to be included in messages.
video/mpeg [RFC1521]
Content-Transfer-Encoding:
Many message transfer agents properly handle only short lines of US-ASCII characters. This is referred to as "7bit" or sometimes as "7bit encoded" text. SMTP imposes this limit. In order to send a richer set of file types across the Internet so that all MTAs can properly process them, some sort of encoding must be used. The purpose of the encoding is to use only 7-bit characters and limited line lengths to represent the content of the file. The file can be an image file, an executable file, or any general binary file.
While there are five content-transfer-encoding values defined, along with the extensible X-token, the base64 and quoted-printable are the only actual encoding schemes defined by MIME. These two schemes offer the extremes in the tradeoff between the need for a compact and efficient scheme and the desire for a generally human-readable scheme. The base64 is a totally mapped and fairly efficient encoding scheme for binary files. The quoted-printable scheme is used for mostly 7-bit data and is readable by humans.
There are three values of content-transfer-encoding that can be used in Internet SMTP messages. The 7bit is the definitive SMTP mechanism. The base64 and quoted-printable are encoding schemes that ensure that the content will properly pass through all MTAs. The 8bit and binary content-transfer-encoding values are defined to explicitly identify content which may require processing or encoding before being packaged for Internet transfer.
Types :
1. 7bit
2. 8bit
3. base64
4. binary
5. quoted-printable
6. X-token
Content-Transfer-Encoding: 7bit
The 7bit is the most fundamental message encoding. Actually, 7bit is not encoded; 7bit encoded files are files that use only 7-bit characters and have lines no longer than 1000 characters. CR (carriage return) and LF (line feed) characters can only occur as pairs to limit the line length to 1000 characters, including the CRLF pair. NULL characters are not allowed. 7bit encoded files need no encoding or decoding. This is the default.
Content-Transfer-Encoding: 8bit
8bit encoding has the same line-length limitations as the 7bit encoding. It allows 8bit characters. No encoding or decoding is required for 8bit files. Since not all MTAs can handle 8bit data, the 8bit encoding is not a valid encoding mechanism for Internet mail.
Content-Transfer-Encoding: base64
Base64 encoding is the scheme used to transmit binary data. Base64 processes data as 24-bit groups, mapping this data to four encoded characters. It is sometimes referred to as 3-to-4 encoding. Each 6 bits of the 24-bit group is used as an index into a mapping table (the base64 alphabet) to obtain a character for the encoded data. The encoded data has line lengths limited to 76 characters. The characters used in base64 encoding, the base64 alphabet, include none of the special characters of importance to SMTP or the hyphen used with MIME boundary strings.
Content-Transfer-Encoding: binary
Binary encoding is simply unencoded binary data. It has no line-length limitations. Binary encoded messages are not valid Internet messages.
Content-Transfer-Encoding: quoted-printable
Quoted-printable encoding is used where data is mostly US-ASCII text. It allows for 8-bit characters to be represented as their hexadecimal values. For instance, a new line can be forced by using the following string: "=0D=0A". Line lengths are limited to 76 characters. Using an equal sign as the last character on the line as a "soft" line break accommodates longer lines. The 76-character limit does not include the CRLF sequence or the equal sign.
Any character, except the CRLF sequence, can be represented by an equal sign followed by a two-digit hexadecimal representation. This is especially useful in getting mostly text messages to pass reliably through gateways such as EBCDIC where such characters as "{" and "}" have special meaning.
Content-Transfer-Encoding: X-token
Private or proprietary encoding schemes can be included in messages by having specialized UAs or applications available to both the sender and the receiver, each recognizing an agreed upon x-token and providing their own encoding mechanism. The x-token can be any character string preceded by "x-" or "X-".
Content-Disposition
Content-Disposition headers are included to allow a message to be tagged to indicate its presentation mechanism or its archival disposition, a file name.
Some UAs may ignore Content-Disposition headers when they appear within multipart/related body parts.
Content-Disposition headers cannot contain comments.
Content-Disposition: attachment
Body parts designated as containing attachments require user action to be displayed. and are normally split out of the message. They are typically stored as files for subsequent access. The optional parameters for this header are: file name, creation-date, modification-date, read-date, and size.
Content-Disposition: inline
Inline content is displayed to the user when the message is opened. The inline body parts are to be displayed in the order they appear in the message, subject to applicable rules for multipart content type. If a multipart body part has an inline header, the inline designation applies to the multipart as a whole, not to its subparts.
No comments:
Post a Comment