Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]
Replaces RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1342: Representation of Non-ASCII Text in Internet Message Headers, RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1590: Media Type Registration Procedure.
This document is current and has been amended. 4 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 4 must, 0 should, 2 may.
4 MIME-Version Header Field
- MUSTMessages composed in accordance with this document MUST include such a header field, with the following verbatim text:
6.7 Quoted-Printable Content-Transfer-Encoding
- MAY(2) (Literal representation) Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the US-ASCII characters which correspond to those octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN through TILDE, respectively).
- MAY(3) (White Space) Octets with values of 9 and 32 MAY be represented as US-ASCII TAB (HT) and SPACE characters,
- MUST NOTrespectively, but MUST NOT be so represented at the end of an encoded line.
- MUSTAny TAB (HT) or SPACE characters on an encoded line MUST thus be followed on that line by a printable character.
- MUST NOTtransport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports.