becomes:

       phrase = 1*(encoded-word / word)

       In this case the set of characters that may be used in a "Q"-
       encoded encoded-word is restricted to: <upper and lower case
       ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and
       "_" (underscore, ASCII 95.)>.  An encoded-word that appears
       within a "phrase" MUST be separated from any adjacent "word",
       "text" or "special" by linear-white-space.

   These are the ONLY locations where an encoded-word may appear.  In
   particular, an encoded-word MUST NOT appear in any portion of an
   "addr-spec".  In addition, an encoded-word MUST NOT be used in a
   Received header field.

   Each encoded-word MUST encode an integral number of octets.  The
   encoded-text in each encoded-word must be well-formed according to
   the encoding specified; the encoded-text may not be continued in the
   next encoded-word.  (For example, "=?charset?Q?=?= =?charset?Q?AB?="
   would be illegal, because the two hex digits "AB" must follow the "="
   in the same encoded-word.)

   Each encoded-word MUST represent an integral number of characters. A
   multi-octet character may not be split across adjacent encoded-words.

   Only printable and white space character data should be encoded using
   this scheme.  However, since these encoding schemes allow the
   encoding of arbitrary octet values, mail readers that implement this
   decoding should also ensure that display of the decoded data on the
   recipient's terminal will not cause unwanted side-effects.

   Use of these methods to encode non-textual data (e.g., pictures or
   sounds) is not defined by this memo.  Use of encoded-words to




 
RFC 1522                     MIME Part Two                September 1993


   represent strings of purely ASCII characters is allowed, but
   discouraged.  In rare cases it may be necessary to encode ordinary
   text that looks like an encoded-word.

6. Support of encoded-words by mail readers

6.1. Recognition of encoded-words in message headers

   A mail reader must parse the message and body part headers according
   to the rules in RFC 822 to correctly recognize encoded-words.

   Encoded-words are to be recognized as follows:

   (1) Any message or body part header field defined as "*text", or any
       user-defined header field, should be parsed as follows: Beginning
       at the start of the field-body and immediately following each
       occurrence of linear-white-space, each sequence of up to 75
       printable characters (not containing any linear-white-space)
       should be examined to see if it is an encoded-word according to
       the syntax rules in section 2.  Any other sequence of printable
       characters should be treated as ordinary ASCII text.

   (2) Any header field not defined as "*text" should be parsed
       according to the syntax rules for that header field.  However,
       any "word" that appears within a "phrase" should be treated as an
       encoded-word if it meets the syntax rules in section 2.
       Otherwise it should be treated as an ordinary "word".

   (3) Within a "comment", any sequence of up to 75 printable characters
       (not containing linear-white-space), that meets the syntax rules
       in section 2, should be treated as an encoded-word.  Otherwise it
       should be treated as normal comment text.

6.2. Display of encoded-words

   Any encoded-words so recognized are decoded, and if possible, the
   resulting unencoded text is displayed in the original character set.

   When displaying a particular header field that contains multiple
   encoded-words, any linear-white-space that separates a pair of
   adjacent encoded-words is ignored.  (This is to allow the use of
   multiple encoded-words to represent long strings of unencoded text,
   without having to separate encoded-words where spaces occur in the
   unencoded text.)

   In the event other encodings are defined in the future, and the mail
   reader does not support the encoding used, it may either (a) display
   the encoded-word as ordinary text, or (b) substitute an appropriate




 
RFC 1522                     MIME Part Two                September 1993


   message indicating that the text could not be decoded.