Editing MIME (section)

==MIME header fields==
===MIME-Version===
The presence of this header field indicates the message is MIME-formatted. The value is typically "1.0". The field appears as follows:
 MIME-Version: 1.0

According to MIME co-creator [[Nathaniel Borenstein]], the version number was introduced to permit changes to the MIME protocol in subsequent versions. However, Borenstein admitted short-comings in the specification that hindered the implementation of this feature: ''"We did not adequately specify how to handle a future MIME version. ... So if you write something that knows 1.0, what should you do if you encounter 2.0 or 1.1? I sort of thought it was obvious but it turned out everyone implemented that in different ways. And the result is that it would be just about impossible for the Internet to ever define a 2.0 or a 1.1."''<ref>{{cite web |title=History of MIME |url=https://www.networkworld.com/article/719139/uc-voip-the-mime-guys-how-two-internet-gurus-changed-e-mail-forever.html |publisher=[[Network World]]|date=February 2011 }}</ref>

===Content-Type===
This header field indicates the [[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 mail 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.
This mechanism supports (non-exhaustively):
* '''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 that the type of file is indicated both by the MIME content-type and the (usually [[Operating System|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/jpeg'', ''audio/mp3'', ''video/mp4'', ''application/msword'', among others).

===Content-Disposition===
The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in RFC 2183 to specify the presentation style. A MIME part can have:
* an ''inline'' content disposition, which means that it should be automatically displayed when the message is displayed, or
* an ''attachment'' content disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.
In addition to the presentation style, the field ''Content-Disposition'' also provides parameters for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.

The following example is taken from RFC 2183, where the header field is defined:
 Content-Disposition: attachment; filename=genome.jpeg;
   modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

The filename may be encoded as defined in RFC 2231.

As of 2010, a majority of [[email client|mail user agents]] did not follow this prescription fully. The widely used [[Mozilla Thunderbird]] mail client ignores the ''content-disposition'' fields in the messages and uses independent algorithms for selecting the MIME parts to display automatically. Thunderbird prior to version 3 also sends out newly composed messages with ''inline'' content disposition for all MIME parts. Most users are unaware of how to set the content disposition to ''attachment''.<ref name="Giles Turnbull">{{Cite web|url=http://www.oreillynet.com/mac/blog/2005/12/forcing_thunderbird_to_treat_o.html |title=Forcing Thunderbird to treat outgoing attachments properly |access-date=2010-04-01 |author=Giles Turnbull |author-link=Giles Turnbull | date=2005-12-14 |publisher=O'Reilly mac devcenter}}</ref> Many mail user agents also send messages with the file name in the ''name'' parameter of the ''content-type'' header instead of the ''filename'' parameter of the header field ''Content-Disposition''. This practice is discouraged, as the file name should be specified either with the parameter ''filename'', or with both the parameters ''filename'' and ''name''.<ref name="ned+ietf-smtp">{{Cite web|url=https://mailarchive.ietf.org/arch/msg/ietf-smtp/KtN0TdoHDayKvKycNbsFD-GB-e4|title=name and filename parameters|date=2008-06-22|access-date=2017-04-03|author=Ned Freed|author-link=Ned Freed}}</ref>

In HTTP, the response header field ''Content-Disposition: attachment'' is usually used as a hint to the client to present the response body as a downloadable file. Typically, when receiving such a response, a [[Web browser]] prompts the user to save its content as a file, instead of displaying it as a page in a browser window, with ''filename'' suggesting the default file name.

===Content-Transfer-Encoding===
In June 1992, MIME (RFC 1341, since made obsolete by RFC 2045) defined a set of methods for representing binary data in formats other than ASCII text format. The ''content-transfer-encoding:'' MIME header field 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:
# If such a binary-to-text encoding method has been used, it states which one.
# If not, it provides a descriptive label for the format of content, with respect to the presence of 8-bit or binary content.

The RFC and the [https://www.iana.org/assignments/transfer-encodings IANA's list] of transfer encodings define the values shown below, which are not case sensitive. '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header field 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.g. UTF-8).
* Suitable for use with normal SMTP:
** '''7bit''' – up to 998 [[Octet (computing)|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. 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. Designed to be efficient for non-text 8 bit and binary 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 (RFC 6152):
**'''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.
* Suitable 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, if BINARYMIME isn't supported, base64 or quoted-printable (with their associated inefficiency) are sometimes still useful. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or [[Message Transmission Optimization Mechanism|MTOM]].