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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Network Working Group                                         N. Freed
Request for Comments: 2231                                    Innosoft
Updates: 2045, 2047, 2183                                     K. Moore
Obsoletes: 2184                                University of Tennessee
Category: Standards Track                                November 1997

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

Status of this Memo

   This document 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" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

1.  Abstract

   This memo defines extensions to the RFC 2045 media type and RFC 2183
   disposition parameter value mechanisms to provide

    (1)   a means to specify parameter values in character sets
          other than US-ASCII,

    (2)   to specify the language to be used should the value be
          displayed, and

    (3)   a continuation mechanism for long parameter values to
          avoid problems with header line wrapping.

   This memo also defines an extension to the encoded words defined in
   RFC 2047 to allow the specification of the language to be used for
   display as well as the character set.

2.  Introduction

   The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC-
   2046, RFC-2047, RFC-2048, RFC-2049], define a message format that
   allows for:

Freed & Moore               Standards Track                     [Page 1]
RFC 2231         MIME Value and Encoded Word Extensions    November 1997

    (1)   textual message bodies in character sets other than
          US-ASCII,

    (2)   non-textual message bodies,

    (3)   multi-part message bodies, and

    (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

Freed & Moore               Standards Track                     [Page 2]
RFC 2231         MIME Value and Encoded Word Extensions    November 1997

          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.

   This document defines extensions that address all of these
   limitations. All of these extensions are implemented in a fashion
   that is completely compatible at a syntactic level with existing MIME
   implementations. In addition, the extensions are designed to have as
   little impact as possible on existing uses of MIME.

   IMPORTANT NOTE:  These mechanisms end up being somewhat gibbous when
   they actually are used. As such, these mechanisms should not be used