RFC 2184 (rfc2184) - Page 2 of 9

MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations

Alternative Format: Original Text Document


RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997


    (4)   textual header information in character sets other than
          US-ASCII.

   MIME is now widely deployed and is used by a variety of Internet
   protocols, including, of course, Internet email.  However, MIME's
   success has resulted in the need for additional mechanisms that were
   not provided in the original protocol specification.

   In particular, existing MIME mechanisms provide for named media type
   (content-type field) parameters as well as named disposition
   (content-disposition field).  A MIME media type may specify any
   number of parameters associated with all of its subtypes, and any
   specific subtype may specify additional parameters for its own use. A
   MIME disposition value may specify any number of associated
   parameters, the most important of which is probably the attachment
   disposition's filename parameter.

   These parameter names and values end up appearing in the content-type
   and content-disposition header fields in Internet email.  This
   inherently imposes three crucial limitations:

    (1)   Lines in Internet email header fields are folded according to
          RFC 822 folding rules.  This makes long parameter values
          problematic.

    (2)   MIME headers, like the RFC 822 headers they often appear in,
          are limited to 7bit US-ASCII, and the encoded-word mechanisms
          of RFC 2047 are not available to parameter values.  This makes
          it impossible to have parameter values in character sets other
          than US-ASCII without specifying some sort of private per-
          parameter encoding.

    (3)   It has recently become clear that character set information
          is not sufficient to properly display some sorts of
          information -- language information is also needed [RFC-2130].
          For example, support for handicapped users may require reading
          text string aloud. The language the text is written in is
          needed for this to be done correctly.  Some parameter values
          may need to be displayed, hence there is a need to allow for
          the inclusion of language information.

   The last problem on this list is also an issue for the encoded words
   defined by RFC 2047, as encoded words are intended primarily for
   display purposes.







Freed & Moore               Standards Track

Web Standards & Support: