an unencoded form which can be parsed by an RFC 822 mail reader.





 
RFC 2047               Message Header Extensions           November 1996


   When displaying a particular header field that contains multiple
   'encoded-word's, any 'linear-white-space' that separates a pair of
   adjacent 'encoded-word's is ignored.  (This is to allow the use of
   multiple 'encoded-word's to represent long strings of unencoded text,
   without having to separate 'encoded-word's 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
   message indicating that the text could not be decoded.

   If the mail reader does not support the character set used, it may
   (a) display the 'encoded-word' as ordinary text (i.e., as it appears
   in the header), (b) make a "best effort" to display using such
   characters as are available, or (c) substitute an appropriate message
   indicating that the decoded text could not be displayed.

   If the character set being used employs code-switching techniques,
   display of the encoded text implicitly begins in "ASCII mode".  In
   addition, the mail reader must ensure that the output device is once
   again in "ASCII mode" after the 'encoded-word' is displayed.

6.3. Mail reader handling of incorrectly formed 'encoded-word's

   It is possible that an 'encoded-word' that is legal according to the
   syntax defined in section 2, is incorrectly formed according to the
   rules for the encoding being used.   For example:

   (1) An 'encoded-word' which contains characters which are not legal
       for a particular encoding (for example, a "-" in the "B"
       encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),
       is incorrectly formed.

   (2) Any 'encoded-word' which encodes a non-integral number of
       characters or octets is incorrectly formed.

   A mail reader need not attempt to display the text associated with an
   'encoded-word' that is incorrectly formed.  However, a mail reader
   MUST NOT prevent the display or handling of a message because an
   'encoded-word' is incorrectly formed.

7. Conformance

   A mail composing program claiming compliance with this specification
   MUST ensure that any string of non-white-space printable ASCII
   characters within a '*text' or '*ctext' that begins with "=?" and
   ends with "?=" be a valid 'encoded-word'.  ("begins" means: at the




 
RFC 2047               Message Header Extensions           November 1996


   start of the field-body, immediately following 'linear-white-space',
   or immediately following a "(" for an 'encoded-word' within '*ctext';
   "ends" means: at the end of the field-body, immediately preceding
   'linear-white-space', or immediately preceding a ")" for an
   'encoded-word' within '*ctext'.)  In addition, any 'word' within a
   'phrase' that begins with "=?" and ends with "?=" must be a valid
   'encoded-word'.

   A mail reading program claiming compliance with this specification
   must be able to distinguish 'encoded-word's from 'text', 'ctext', or
   'word's, according to the rules in section 6, anytime they appear in
   appropriate places in message headers.  It must support both the "B"
   and "Q" encodings for any character set which it supports.  The
   program must be able to display the unencoded text if the character
   set is "US-ASCII".  For the ISO-8859-* character sets, the mail
   reading program must at least be able to display the characters which
   are also in the ASCII set.

8. Examples

   The following are examples of message headers containing 'encoded-
   word's:

   From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
   CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be>
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

      Note: In the first 'encoded-word' of the Subject field above, the
      last "=" at the end of the 'encoded-text' is necessary because each
      'encoded-word' must be self-contained (the "=" character completes a
      group of 4 base64 characters representing 2 octets).  An additional
      octet could have been encoded in the first 'encoded-word' (so that