encodings are described below.  The "Q" encoding is recommended for
   use when most of the characters to be encoded are in the ASCII
   character set; otherwise, the "B" encoding should be used.
   Nevertheless, a mail reader which claims to recognize encoded-words
   MUST be able to accept either encoding for any character set which it
   supports.

   Only a subset of the printable ASCII characters may be used in
   encoded-text.  Space and tab characters are not allowed, so that the
   beginning and end of an encoded-word are obvious.  The "?" character
   is used within an encoded-word to separate the various portions of
   the encoded-word from one another, and thus cannot appear in the
   encoded-text portion.  Other characters are also illegal in certain
   contexts.  For example, an encoded-word in a "phrase" preceding an
   address in a From header field may not contain any of the "specials"
   defined in RFC 822.  Finally, certain other characters are disallowed
   in some contexts, to ensure reliability for messages that pass
   through internetwork mail gateways.

   The "B" encoding automatically meets these requirements.  The "Q"
   encoding allows a wide range of printable characters to be used in
   non-critical locations in the message header (e.g., Subject), with




 
RFC 1522                     MIME Part Two                September 1993


   fewer characters available for use in other locations.

4.1. The "B" encoding

   The "B" encoding is identical to the "BASE64" encoding defined by RFC
   1521.

4.2. The "Q" encoding

   The "Q" encoding is similar to the "Quoted-Printable" content-
   transfer-encoding defined in RFC 1521.  It is designed to allow text
   containing mostly ASCII characters to be decipherable on an ASCII
   terminal without decoding.

   (1) Any 8-bit value may be represented by a "=" followed by two
       hexadecimal digits.  For example, if the character set in use
       were ISO-8859-1, the "=" character would thus be encoded as
       "=3D", and a SPACE by "=20".  (Upper case should be used for
       hexadecimal digits "A" through "F".)

   (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
       represented as "_" (underscore, ASCII 95.).  (This character may
       not pass through some internetwork mail gateways, but its use
       will greatly enhance readability of "Q" encoded data with mail
       readers that do not support this encoding.)  Note that the "_"
       always represents hexadecimal 20, even if the SPACE character
       occupies a different code position in the character set in use.

   (3) 8-bit values which correspond to printable ASCII characters other
       than "=", "?", "_" (underscore), and SPACE may be represented as
       those characters.  (But see section 5 for restrictions.)

5. Use of encoded-words in message headers

   An encoded-word may appear in a message header or body part header
   according to the following rules:

   (1) An encoded-word may replace a "text" token (as defined by RFC
       822) in any Subject or Comments header field, any extension
       message header field, or any RFC 1521 body part field for which
       the field body is defined as "*text".  An encoded-word may also
       appear in any user-defined ("X-") message or body part header
       field.

       Ordinary ASCII text and encoded-words may appear together in the
       same header field.  However, an encoded-word that appears in a
       header field defined as "*text" MUST be separated from any
       adjacent encoded-word or "text" by linear-white-space.




 
RFC 1522                     MIME Part Two                September 1993


   (2) An encoded-word may appear within a comment delimited by "(" and
       ")", i.e., wherever a "ctext" is allowed.  More precisely, the
       RFC 822 ABNF definition for "comment" is amended as follows:

       comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"

       A "Q"-encoded encoded-word which appears in a comment MUST NOT
       contain the characters "(", ")" or " encoded-word that appears in
       a "comment" MUST be separated from any adjacent encoded-word or
       "ctext" by linear-white-space.

   (3) As a replacement for a "word" entity within a "phrase", for
       example, one that precedes an address in a From, To, or Cc
       header.  The ABNF definition for phrase from RFC 822 thus