MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
RFC 1522
Document | Type |
RFC - Draft Standard
(September 1993; Errata)
Obsoletes RFC 1342
|
|
---|---|---|---|
Author | Keith Moore | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1522 (Draft Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group K. Moore Request for Comments: 1522 University of Tennessee Obsoletes: 1342 September 1993 Category: Standards Track MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text Status of this Memo This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo describes an extension to the message format defined in RFC 1521 [1], to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. 1. Introduction RFC 1521 describes a mechanism for denoting textual body parts which are coded in various character sets, as well as methods for encoding such body parts as sequences of printable ASCII characters. This memo describes similar techniques to allow the encoding of non-ASCII text in various portions of a RFC 822 [2] message header, in a manner which is unlikely to confuse existing message handling software. Like the encoding techniques described in RFC 1521, the techniques outlined here were designed to allow the use of non-ASCII characters in message headers in a way which is unlikely to be disturbed by the quirks of existing Internet mail handling programs. In particular, some mail relaying programs are known to (a) delete some message header fields while retaining others, (b) rearrange the order of addresses in To or Cc fields, (c) rearrange the (vertical) order of header fields, and/or (d) "wrap" message headers at different places than those in the original message. In addition, some mail reading programs are known to have difficulty correctly parsing message headers which, while legal according to RFC 822, make use of backslash-quoting to "hide" special characters such as "<", ",", or ":", or which exploit other infrequently-used features of that Moore [Page 1] RFC 1522 MIME Part Two September 1993 specification. While it is unfortunate that these programs do not correctly interpret RFC 822 headers, to "break" these programs would cause severe operational problems for the Internet mail system. The extensions described in this memo therefore do not rely on little- used features of RFC 822. Instead, certain sequences of "ordinary" printable ASCII characters (known as "encoded-words") are reserved for use as encoded data. The syntax of encoded-words is such that they are unlikely to "accidentally" appear as normal text in message headers. Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears. Generally, an "encoded-word" is a sequence of printable ASCII characters that begins with "=?", ends with "?=", and has two "?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method. A mail composer that implements this specification will provide a means of inputting non-ASCII text in header fields, but will translate these fields (or appropriate portions of these fields) into encoded-words before inserting them into the message header. A mail reader that implements this specification will recognize encoded-words when they appear in certain portions of the message header. Instead of displaying the encoded-word "as is", it will reverse the encoding and display the original text in the designated character set. NOTES This memo relies heavily on notation and terms defined STD 11, RFC 822 and RFC 1521. In particular, the syntax for the ABNF used in this memo is defined in STD 11, RFC 822, as well as many of the terms used in the grammar for the header extensions defined here. Successful implementation of this protocol extension requires careful attention to the details of both STD 11, RFC 822 and RFC 1521. When the term "ASCII" appears in this memo, it refers to the "7- Bit American Standard Code for Information Interchange", ANSI X3.4-1986. The MIME charset name for this character set is "US- ASCII". When not specifically referring to the MIME charset name,Show full document text