Internet standard MIME is able to extend the e-mail format for the purpose to support the following things as text, non-text attachment, a message organization with manifold parts and non-ASCII header information. The existence of MIME protocol has become very important because SMTP as basic e-mail transmission protocol can support only 7-bit of ASCII characters set. But MIME as Presentation layer protocol can hold up 8-bit binary content by describing the ways of sending certain types of data via an electronic mail. But data types are including that text other than English language too, files with images, sounds, or movies, etc. MIME also specified about the set of e-mail’s headers to facilitate a message additional attributes specification, which may include content type, and description of transfer encoding set. MIME is as well specified the set of laws and non-ASCII character’s encoding in the message headers of e-mail. But when RFC 822-style header’s practice is being made for the attributes of MIME message then without making any change to on hand email servers, plain texted e-mails are permitted to play their role in both directions with reachable clients. But all this is possible when MIME headers are declared optional.
Anyway, following RFCs are mentioned here for your better understanding regarding the subject. RFC 1426 is dealt with 8bit MIME transportation. But RFC 1847 specifies the MIME security multiparts while RFC 3156 describes MIME security by means of OpenPGP. Similarly, RFC 2183 is dealt with the information regarding communicating presentation in e-mail messages. RFC 2387 is related with MIME multipart or related content-type but RFC 1521 covers that mechanism specifies the Internet Messaging Bodies format. Extensible MIME definition is included a scheme to schedule fresh contents types and attribute values of MIME.
Typical Header fields of MIME
Header’s typical fields are as under:
- MIME-Version such a
s MIME-version: 1.0. B
ut all of MIME headers must include comments enclosed within parentheses such as following comment like
(generated by application 1.3)
can be added with MIME version specification
, etc.
- Content-Type is not necessary with RFC 2045 confirmed document. But MIME parser is requisite a top ranked Content-Type.
- Syntax of MIME header can be mentioned below as:
Content-Type: type/subtype;parameterBoth type and as well subtype is used to define the type of content. But all other not obligatory parameters will be surrounded by semicolons. Following table is displayed with some common values of Content-Type.
|
Content-Type |
explanation |
| text/xml | Used along with SwA . |
| application/xml | Utilized for xml data that is application specific. |
| multipart/signed | Employed for several related parts within a message. |
| multipart/mixed | Employed for various self-sufficient parts within a message. |
- Content Transfer Encoding header’s field is utilized to point out the form of transformation with which this data type is encoded into a 7-bit set-up.
- Content-ID is an optional field, which facilitates parts labeling.
- Content-Description is an optional field, which facilitates parts depiction.
MIME encodings is performed in the form of base64 and quoted-printable encoding according to RFC 1521. In case of base64, the actual data is divided into 3 octets groups but quoted-printable encoding is suitable for the data included printable characters as 33-60 characters range and 62-126 characters range.