MIME

For mime as an art form, see Mime artist. For members of the British engineering society, see Institution of Mechanical Engineers. The Institution of Mechanical Engineers (IMechE is the British Engineering society concerned with Mechanical engineering

Multipurpose Internet Message Extensions (MIME) is an Internet standard that extends the format of e-mail to support:

text in character sets other than US-ASCII;
non-text attachments;
message bodies with multiple parts; and
header information in non-ASCII character sets. In Computer network Engineering, an Internet Standard (STD is a Specification, put forward by the Internet Engineering Task Force (IETF for Electronic mail, often abbreviated to e-mail, email, or originally eMail, is a Store-and-forward method of writing sending receiving A character encoding consists of a code that pairs a sequence of characters from a given character set (sometimes incorrectly referred to as Code page American Standard Code for Information Interchange ( ASCII)

MIME's use, however, has grown beyond describing the content of e-mail to describing content type in general. Electronic mail, often abbreviated to e-mail, email, or originally eMail, is a Store-and-forward method of writing sending receiving

Virtually all human-written Internet e-mail and a fairly large proportion of automated e-mail is transmitted via SMTP in MIME format. The Internet is a global system of interconnected Computer networks Simple Mail Transfer Protocol ( SMTP) is a De facto standard for electronic mail (e-mail transmissions across the Internet. Internet e-mail is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME e-mail. [1]

The content types defined by MIME standards are also of importance outside of e-mail, such as in communication protocols like HTTP for the World Wide Web. In computing, a protocol is a convention or standard that controls or enables the connection Communication, and Data transfer between two computing Hypertext Transfer Protocol ( HTTP) is a Communications protocol for the transfer of information on the Internet. The World Wide Web (commonly shortened to the Web) is a system of interlinked Hypertext documents accessed via the Internet. HTTP requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail.

MIME is specified in six linked RFC memorandum : RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2077, which together define the specifications. In Computer network Engineering, a Request for Comments (RFC is a Memorandum published by the Internet Engineering Task Force (IETF describing

Introduction

The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). American Standard Code for Information Interchange ( ASCII) 8BITMIME (RFC 1652 is an SMTP extension standardized in 1994 that facilitates the exchange of E-mail messages containing octets outside the seven-bit This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English. English is a West Germanic language originating in England and is the First language for most people in the United Kingdom, the United States Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail. A diacritic ( also called a diacritic or diacritical mark, point, or sign, is a small sign added to a letter to alter pronunciation

MIME defines mechanisms for sending other kinds of information in e-mail. These include text in languages other than English using character encodings other than ASCII, and 8-bit binary content such as files containing images, sounds, movies, and computer programs. A character encoding consists of a code that pairs a sequence of characters from a given character set (sometimes incorrectly referred to as Code page An image (from Latin imago) or picture is an artifact usually two-dimensional that has a similar appearance to some subject &mdashusually Sound' is Vibration transmitted through a Solid, Liquid, or Gas; particularly sound means those vibrations composed of Frequencies Computer programs (also software programs, or just programs) are instructions for a Computer. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages even though the data might not fit this context. Hypertext Transfer Protocol ( HTTP) is a Communications protocol for the transfer of information on the Internet. Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail. An e-mail client, aka Mail User Agent (MUA aka e-mail reader is a frontend Computer program used to manage E-mail. A mail transfer agent (MTA (also called a mail transport agent, message transfer agent, or smtpd (short for SMTP daemon) is a

The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". In Information technology, header refers to supplemental Data placed at the beginning of a block of data being stored or transmitted MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.

MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.

The goals of the MIME definition included requiring no changes to extant e-mail servers, and allowing plain text e-mail to function in both directions with extant clients. These goals were achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client. A simple MIME text message is therefore likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ASCII part of the message will be intelligible to users with non-MIME clients.

MIME headers

MIME-Version

The presence of this header indicates the message is MIME-formatted. The value is typically "1. 0" so this header appears as

MIME-Version: 1. 0

It should be noted that implementers have attempted to change the version number in the past and the change had unforeseen results. It was decided at an IETF meeting to leave the version number as is even though there have been many updates and versions of MIME.

Content-Type

This header indicates the Internet media type of the message content, consisting of a type and subtype, for example

Content-Type: text/plain

Through the use of the multipart type, MIME allows messages to have parts arranged in a tree structure where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of a variety of multipart types. An Internet media type, originally called a MIME type after MIME and sometimes a Content-type after the name of a header in several protocols whose value A tree structure is a way of representing the hierarchical nature of a Structure in a graphical form This mechanism supports:

simple text messages using text/plain (the default value for "Content-type:")
text plus attachments (multipart/mixed with a text/plain part and other non-text parts). A MIME message including an attached file generally indicates the file's original name with the "Content-disposition:" header, so the type of file is indicated both by the MIME content-type and the (usually OS-specific) filename extension
reply with original attached (multipart/mixed with a text/plain part and the original message as a message/rfc822 part)
alternative content, such as a message sent in both plain text and another format such as HTML (multipart/alternative with the same content in text/plain and text/html forms)
image, audio, video and application (for example, image/jpg, audio/mp3, video/mp4, and application/mswork and so on)
many other message constructs

Content-Transfer-Encoding

In June 1992, MIME (RFC 1341, since obsoleted by RFC 2045) defined a set of methods for representing binary data in ASCII text format. An operating system (commonly abbreviated OS and O/S) is the software component of a Computer system that is responsible for the management and coordination A filename extension is a suffix to the name of a Computer file applied to indicate the encoding convention ( File format) of its contents HTML, an initialism of HyperText Markup Language, is the predominant Markup language for Web pages It provides a means to describe the structure Year 1992 ( MCMXCII) was a Leap year starting on Wednesday (link will display full 1992 Gregorian calendar) The content-transfer-encoding: MIME header has 2-sided significance:

It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header, and
If such a binary-to-text encoding method has been used it states which one. A binary-to-text encoding is encoding of data in Plain text. More precisely it is an encoding of Binary data in a sequence of ASCII -printable

The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive. Note that '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header is actually redundant for the email client to decode the message body, but it may still be useful as an indicator of what type of object is being sent. Values 'quoted-printable' and 'base64' tell the email client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e. Quoted-printable, or QP encoding, is an encoding using printable characters (i The term Base64 refers to a specific MIME content transfer encoding. g. UTF-8).

Suitable for use with normal SMTP:
- 7bit — up to 998 octets per line of the code range 1. . 127 with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending. This is the default value.
- quoted-printable — used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Quoted-printable, or QP encoding, is an encoding using printable characters (i Designed to be efficient and mostly human readable when used for text data consisting primarily of US-ASCII characters but also containing a small proportion of bytes with values outside that range.
- base64 — used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. The term Base64 refers to a specific MIME content transfer encoding. Designed to be efficient for non-text 8 bit data. Sometimes used for text data that frequently uses non-US-ASCII characters.
Suitable for use with SMTP servers that support the 8BITMIME SMTP extension:
- 8bit — up to 998 octets per line with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending. 8BITMIME (RFC 1652 is an SMTP extension standardized in 1994 that facilitates the exchange of E-mail messages containing octets outside the seven-bit Extended SMTP (ESMTP sometimes referred to as Enhanced SMTP, is a definition of protocol extensions to the Simple Mail Transfer Protocol standard
Suitable only for use with SMTP servers that support the BINARYMIME SMTP extension (RFC 3030):
- binary — any sequence of octets.

There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension. Thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM

Encoded-Word

Since RFC 2822, message header names and values are always ASCII characters; values that contain non-ASCII data must use the MIME encoded-word syntax (RFC 2047) instead of a literal string. MTOM is the W3C Message Transmission Optimization Mechanism,a method of efficiently sending binary data to and from Web services It uses XOP This syntax uses a string of ASCII characters indicating both the original character encoding (the "charset") and the content-transfer-encoding used to map the bytes of the charset into ASCII characters.

The form is: "=?charset?encoding?encoded text?=".

charset may be any character set registered with IANA. The Internet Assigned Numbers Authority (IANA is the entity that oversees global IP address allocation, DNS root zone management, media types Typically it would be the same charset as the message body.
encoding can be either "Q" denoting Q-encoding that is similar to the quoted-printable encoding, or "B" denoting base64 encoding. Quoted-printable, or QP encoding, is an encoding using printable characters (i The term Base64 refers to a specific MIME content transfer encoding.
encoded text is the Q-encoded or base64-encoded text.

Difference between Q-encoding and quoted-printable

The ASCII codes for the question mark (?) and equals sign may not be represented directly as they are used to delimit the encoded-word. The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably. To make the encoding smaller and easier to read the underscore is used to represent the ASCII code for space creating the side effect that underscore cannot be represented directly. Use of encoded words in certain parts of headers imposes further restrictions on which characters may be represented directly.

For example,

Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

is interpreted as "Subject: ¡Hola, señor!".

The encoded-word format is not used for the names of the headers (for example Subject). These header names are always in English in the raw message. When viewing a message with a non-English e-mail client, the header names are usually translated by the client.

Multipart messages

A MIME multipart message contains a boundary in the "Content-type:" header; this boundary, which must not occur in any of the parts, is placed between the parts, and at the beginning and end of the body of the message, as follows:

MIME-version: 1. A delimiter is a sequence of one or more characters used to specify the boundary between separate independent regions in Plain text or other data stream 0
Content-type: multipart/mixed; boundary="frontier"

This is a message with multiple parts in MIME format. 
--frontier
Content-type: text/plain

This is the body of the message. 
--frontier
Content-type: application/octet-stream
Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.

Notes:

Before the first boundary is an area that is ignored by MIME compliant clients. This area is generally used to put a message to users of old non-MIME clients.
It is up to the sending mail client to choose a boundary string that doesn't clash with the body text. Typically this is done by inserting a large random string.

Multipart subtypes

The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another. The subtype is specified in the "Content-Type" header of the overall message. For example, a multipart MIME message using the digest subtype would have its Content-Type set as "multipart/digest".

The RFC initially defined 4 subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.

The following is a list of the most commonly used subtypes; it is not intended to be a comprehensive list.

Mixed

Multipart/mixed is used for sending files with different "Content-Type" headers inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless otherwise specified with the "Content-disposition" header). Otherwise it will offer them as attachments. The default content-type for each part is "text/plain".

Defined in RFC 2046, Section 5.1.3

Message

A message/rfc822 part contains an email message, including any headers. Electronic mail, often abbreviated to e-mail, email, or originally eMail, is a Store-and-forward method of writing sending receiving Rfc822 is a misnomer, since the message may be a full MIME message. A misnomer is a term which suggests an interpretation that is known to be untrue This is used for digests as well as for E-mail forwarding. Email forwarding consists of the operation of re-sending an email message delivered to one Email address on to another email address

Defined in RFC 2046.

Digest

Multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".

Defined in RFC 2231, Section 5.1.5

Alternative

The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The formats are ordered by how faithful they are to the original, with the least faithful first and the most faithful last. Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.

Since a client is unlikely to want to send a version that is less faithful than the plain text version this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.

Most commonly multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html). HTML e-mail is the use of a Subset of HTML (often ill-defined to provide formatting and semantic markup capabilities in E-mail that are not The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.

While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, anti-spam filters would only examine the text/plain part of a message, because it is easier to parse than the text/html part. E-mail spam, also known as "bulk e-mail" or "junk e-mail" is a subset of spam that involves nearly identical messages sent to numerous recipients by But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.

Defined in RFC 2046, Section 5.1.4

A multipart/related is used to indicate that message parts should not be considered individually but rather as parts of an aggregate whole. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by the "Content-ID" part header. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.

One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the HTML document, and use image tags to reference images stored in the latter parts. HTML, an initialism of HyperText Markup Language, is the predominant Markup language for Web pages It provides a means to describe the structure

Defined in RFC 2387

Report

Multipart/report is a message type that contains data formatted for a mail server to read. It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for the mail server to read.

Defined in RFC 3462

Signed

A multipart/signed message is used to attach a digital signature to a message. A digital signature or digital signature scheme is a type of asymmetric cryptography used to simulate the security properties of a handwritten Signature It has two parts, a body part and a signature part. The whole of the body part, including mime headers, is used to create the signature part. Many signature types are possible, like application/pgp-signature (RFC 3156) and application/x-pkcs7-signature (S/MIME). S/MIME ( Secure / Multipurpose Internet Mail Extensions) is a standard for Public key Encryption and signing of E-mail encapsulated

Defined in RFC 1847, Section 2.1

Encrypted

A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are identified by their separate content types for the control part. The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME). S/MIME ( Secure / Multipurpose Internet Mail Extensions) is a standard for Public key Encryption and signing of E-mail encapsulated

Defined in RFC 1847, Section 2.2

Form Data

As its name implies, multipart/form-data is used to express values submitted through a form. Originally defined as part of HTML 4. HTML, an initialism of HyperText Markup Language, is the predominant Markup language for Web pages It provides a means to describe the structure 0, it is most commonly used for submitting files via HTTP. Hypertext Transfer Protocol ( HTTP) is a Communications protocol for the transfer of information on the Internet.

Defined in RFC 2388

Mixed-Replace (Experimental)

The content type multipart/x-mixed-replace was developed as part of a technology to emulate server push and streaming over HTTP. Push technology, or server push, describes a style of Internet -based communication where the request for a given transaction originates with the publisher or central

All parts of a mixed-replace message have the same semantic meaning. However, each part invalidates - "replaces" - the previous parts as soon as it is received completely. Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.

Originally developed by Netscape, it is still supported by Mozilla, Firefox, Safari (but not in Safari on the iPhone) and Opera, but traditionally ignored by Microsoft. It is commonly used in IP cameras as the MIME type for MJPEG streams.

References

RFC 1426: SMTP Service Extension for 8bit-MIMEtransport. S/MIME ( Secure / Multipurpose Internet Mail Extensions) is a standard for Public key Encryption and signing of E-mail encapsulated A mailcap file can be used to find the correct program to open a file with based on MIME information Many E-mail clients now offer some support for Unicode in E-mail bodies An Internet media type, originally called a MIME type after MIME and sometimes a Content-type after the name of a header in several protocols whose value J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Einar Stefferud (Stef ( 11 January 1930 –) is an Internet pioneer computer researcher and entrepreneur who has made many significant contributions to the development Crocker. February 1993.
RFC 1847: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 3156: MIME Security with OpenPGP
RFC 2045: MIME Part One: Format of Internet Message Bodies.
RFC 2046: MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. Nathaniel Borenstein (b September 23, 1957) is one of the original designers of the MIME protocol for formatting multimedia Internet electronic November 1996.
RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. This article is about the Internet protocol engineer See also Keith L November 1996.
RFC 4288: MIME Part Four: Media Type Specifications and Registration Procedures.
RFC 4289: MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049: MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387: The MIME Multipart/Related Content-type
RFC 1521: Mechanisms for Specifying and Describing the Format of Internet Message Bodies

External links

Dictionary

-acronym

(networking) Multipurpose Internet Mail Extensions, an internet standard which extends the formatting and content capabilities of email.

© 2009 citizendia.org; parts available under the terms of GNU Free Documentation License, from http://en.wikipedia.org
network: | |

Contents