home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2184 < prev    next >
Text File  |  1997-08-29  |  18KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         N. Freed
  8. Request for Comments: 2184                                    Innosoft
  9. Updates: 2045, 2047, 2183                                     K. Moore
  10. Category: Standards Track                      University of Tennessee
  11.                                                            August 1997
  12.  
  13.  
  14.            MIME Parameter Value and Encoded Word Extensions:
  15.               Character Sets, Languages, and Continuations
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. 1.  Abstract
  26.  
  27.    This memo defines extensions to the RFC 2045 media type and RFC 2183
  28.    disposition parameter value mechanisms to provide
  29.  
  30.     (1)   a means to specify parameter values in character sets
  31.           other than US-ASCII,
  32.  
  33.     (2)   to specify the language to be used should the value be
  34.           displayed, and
  35.  
  36.     (3)   a continuation mechanism for long parameter values to
  37.           avoid problems with header line wrapping.
  38.  
  39.    This memo also defines an extension to the encoded words defined in
  40.    RFC 2047 to allow the specification of the language to be used for
  41.    display as well as the character set.
  42.  
  43. 2.  Introduction
  44.  
  45.    The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC-
  46.    2046, RFC-2047, RFC-2048, RFC-2049], define a message format that
  47.    allows for
  48.  
  49.     (1)   textual message bodies in character sets other than
  50.           US-ASCII,
  51.  
  52.     (2)   non-textual message bodies,
  53.  
  54.     (3)   multi-part message bodies, and
  55.  
  56.  
  57.  
  58. Freed & Moore               Standards Track                     [Page 1]
  59.  
  60. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  61.  
  62.  
  63.     (4)   textual header information in character sets other than
  64.           US-ASCII.
  65.  
  66.    MIME is now widely deployed and is used by a variety of Internet
  67.    protocols, including, of course, Internet email.  However, MIME's
  68.    success has resulted in the need for additional mechanisms that were
  69.    not provided in the original protocol specification.
  70.  
  71.    In particular, existing MIME mechanisms provide for named media type
  72.    (content-type field) parameters as well as named disposition
  73.    (content-disposition field).  A MIME media type may specify any
  74.    number of parameters associated with all of its subtypes, and any
  75.    specific subtype may specify additional parameters for its own use. A
  76.    MIME disposition value may specify any number of associated
  77.    parameters, the most important of which is probably the attachment
  78.    disposition's filename parameter.
  79.  
  80.    These parameter names and values end up appearing in the content-type
  81.    and content-disposition header fields in Internet email.  This
  82.    inherently imposes three crucial limitations:
  83.  
  84.     (1)   Lines in Internet email header fields are folded according to
  85.           RFC 822 folding rules.  This makes long parameter values
  86.           problematic.
  87.  
  88.     (2)   MIME headers, like the RFC 822 headers they often appear in,
  89.           are limited to 7bit US-ASCII, and the encoded-word mechanisms
  90.           of RFC 2047 are not available to parameter values.  This makes
  91.           it impossible to have parameter values in character sets other
  92.           than US-ASCII without specifying some sort of private per-
  93.           parameter encoding.
  94.  
  95.     (3)   It has recently become clear that character set information
  96.           is not sufficient to properly display some sorts of
  97.           information -- language information is also needed [RFC-2130].
  98.           For example, support for handicapped users may require reading
  99.           text string aloud. The language the text is written in is
  100.           needed for this to be done correctly.  Some parameter values
  101.           may need to be displayed, hence there is a need to allow for
  102.           the inclusion of language information.
  103.  
  104.    The last problem on this list is also an issue for the encoded words
  105.    defined by RFC 2047, as encoded words are intended primarily for
  106.    display purposes.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Freed & Moore               Standards Track                     [Page 2]
  115.  
  116. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  117.  
  118.  
  119.    This document defines extensions that address all of these
  120.    limitations. All of these extensions are implemented in a fashion
  121.    that is completely compatible at a syntactic level with existing MIME
  122.    implementations. In addition, the extensions are designed to have as
  123.    little impact as possible on existing uses of MIME.
  124.  
  125.    IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when
  126.    they actually are used. As such, use of these mechanisms should not
  127.    be used lightly; they should be reserved for situations where a real
  128.    need for them exists.
  129.  
  130. 2.1.  Requirements notation
  131.  
  132.    This document occasionally uses terms that appear in capital letters.
  133.    When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
  134.    appear capitalized, they are being used to indicate particular
  135.    requirements of this specification. A discussion of the meanings of
  136.    these terms appears in [RFC-2119].
  137.  
  138.  
  139. 3.  Parameter Value Continuations
  140.  
  141.    Long MIME media type or disposition parameter values do not interact
  142.    well with header line wrapping conventions.  In particular, proper
  143.    header line wrapping depends on there being places where linear
  144.    whitespace (LWSP) is allowed, which may or may not be present in a
  145.    parameter value, and even if present may not be recognizable as such
  146.    since specific knowledge of parameter value syntax may not be
  147.    available to the agent doing the line wrapping. The result is that
  148.    long parameter values may end up getting truncated or otherwise
  149.    damaged by incorrect line wrapping implementations.
  150.  
  151.    A mechanism is therefore needed to break up parameter values into
  152.    smaller units that are amenable to line wrapping. Any such mechanism
  153.    MUST be compatible with existing MIME processors. This means that
  154.  
  155.     (1)   the mechanism MUST NOT change the syntax of MIME media
  156.           type and disposition lines, and
  157.  
  158.     (2)   the mechanism MUST NOT depend on parameter ordering
  159.           since MIME states that parameters are not order sensitive.
  160.           Note that while MIME does prohibit modification of MIME
  161.           headers during transport, it is still possible that parameters
  162.           will be reordered when user agent level processing is done.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Freed & Moore               Standards Track                     [Page 3]
  171.  
  172. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  173.  
  174.  
  175.    The obvious solution, then, is to use multiple parameters to contain
  176.    a single parameter value and to use some kind of distinguished name
  177.    to indicate when this is being done.  And this obvious solution is
  178.    exactly what is specified here: The asterisk character ("*") followed
  179.    by a decimal count is employed to indicate that multiple parameters
  180.    are being used to encapsulate a single parameter value.  The count
  181.    starts at 0 and increments by 1 for each subsequent section of the
  182.    parameter value.  Decimal values are used and neither leading zeroes
  183.    nor gaps in the sequence are allowed.
  184.  
  185.    The original parameter value is recovered by concatenating the
  186.    various sections of the parameter, in order.  For example, the
  187.    content-type field
  188.  
  189.      Content-Type: message/external-body; access-type=URL;
  190.       URL*0="ftp://";
  191.       URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
  192.  
  193.    is semantically identical to
  194.  
  195.      Content-Type: message/external-body; access-type=URL;
  196.       URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
  197.  
  198.    Note that quotes around parameter values are part of the value
  199.    syntax; they are NOT part of the value itself.  Furthermore, it is
  200.    explicitly permitted to have a mixture of quoted and unquoted
  201.    continuation fields.
  202.  
  203. 4.  Parameter Value Character Set and Language Information
  204.  
  205.    Some parameter values may need to be qualified with character set or
  206.    language information.  It is clear that a distinguished parameter
  207.    name is needed to identify when this information is present along
  208.    with a specific syntax for the information in the value itself.  In
  209.    addition, a lightweight encoding mechanism is needed to accomodate 8
  210.    bit information in parameter values.
  211.  
  212.    Asterisks ("*") are reused to provide the indicator that language and
  213.    character set information is present and encoding is being used. A
  214.    single quote ("'") is used to delimit the character set and language
  215.    information at the beginning of the parameter value. Percent signs
  216.    ("%") are used as the encoding flag, which agrees with RFC 2047.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Freed & Moore               Standards Track                     [Page 4]
  227.  
  228. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  229.  
  230.  
  231.    Specifically, an asterisk at the end of a parameter name acts as an
  232.    indicator that character set and language information may appear at
  233.    the beginning of the parameter value. A single quote is used to
  234.    separate the character set, language, and actual value information in
  235.    the parameter value string, and an percent sign is used to flag
  236.    octets encoded in hexadecimal.  For example:
  237.  
  238.      Content-Type: application/x-stuff;
  239.       title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
  240.  
  241.    Note that it is perfectly permissible to leave either the character
  242.    set or language field blank.  Note also that the single quote
  243.    delimiters MUST be present even when one of the field values is
  244.    omitted.  This is done when either character set, language, or both
  245.    are not relevant to the parameter value at hand.  This MUST NOT be
  246.    done in order to indicate a default character set or language --
  247.    parameter field definitions MUST NOT assign a default character set
  248.    or lanugage.
  249.  
  250. 4.1.  Combining Character Set, Language, and Parameter Continuations
  251.  
  252.    Character set and language information may be combined with the
  253.    parameter continuation mechanism. For example:
  254.  
  255.    Content-Type: application/x-stuff
  256.     title*1*=us-ascii'en'This%20is%20even%20more%20
  257.     title*2*=%2A%2A%2Afun%2A%2A%2A%20
  258.     title*3="isn't it!"
  259.  
  260.    Note that:
  261.  
  262.     (1)   Language and character set information only appear at
  263.           the beginning of a given parameter value.
  264.  
  265.     (2)   Continuations do not provide a facility for using more
  266.           than one character set or language in the same parameter
  267.           value.
  268.  
  269.     (3)   A value presented using multiple continuations may
  270.           contain a mixture of encoded and unencoded segments.
  271.  
  272.     (4)   The first segment of a continuation MUST be encoded if
  273.           language and character set information are given.
  274.  
  275.     (5)   If the first segment of a continued parameter value is
  276.           encoded the language and character set field delimiters MUST
  277.           be present even when the fields are left blank.
  278.  
  279.  
  280.  
  281.  
  282. Freed & Moore               Standards Track                     [Page 5]
  283.  
  284. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  285.  
  286.  
  287. 5.  Language specification in Encoded Words
  288.  
  289.    RFC 2047 provides support for non-US-ASCII character sets in RFC 822
  290.    message header comments, phrases, and any unstructured text field.
  291.    This is done by defining an encoded word construct which can appear
  292.    in any of these places.  Given that these are fields intended for
  293.    display, it is sometimes necessary to associate language information
  294.    with encoded words as well as just the character set.  This
  295.    specification extends the definition of an encoded word to allow the
  296.    inclusion of such information.  This is simply done by suffixing the
  297.    character set specification with an asterisk followed by the language
  298.    tag.  For example:
  299.  
  300.         From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>
  301.  
  302. 6.  IMAP4 Handling of Parameter Values
  303.  
  304.    IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations
  305.    when generating the BODY and BODYSTRUCTURE fetch attributes.
  306.  
  307. 7.  Modifications to MIME ABNF
  308.  
  309.    The ABNF for MIME parameter values given in RFC 2045 is:
  310.  
  311.    parameter := attribute "=" value
  312.  
  313.    attribute := token
  314.                 ; Matching of attributes
  315.                 ; is ALWAYS case-insensitive.
  316.  
  317.    This specification changes this ABNF to:
  318.  
  319.    parameter := regular-parameter / extended-parameter
  320.  
  321.    regular-parameter := regular-parameter-name "=" value
  322.  
  323.    regular-parameter-name := attribute [section]
  324.  
  325.    attribute := 1*attribute-char
  326.  
  327.    attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
  328.                      "*", "'", "%", or tspecials>
  329.  
  330.    section := initial-section / other-sections
  331.  
  332.    initial-section := "*1"
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Freed & Moore               Standards Track                     [Page 6]
  339.  
  340. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  341.  
  342.  
  343.    other-sections := "*" (("2" / "3" / "4" / "5" /
  344.                            "6" / "7" / "8" / "9") *DIGIT) /
  345.                           ("1" 1*DIGIT))
  346.  
  347.    extended-parameter := (extended-initial-name "="
  348.                           extended-value) /
  349.                          (extended-other-names "="
  350.                           extended-other-values)
  351.  
  352.    extended-initial-name := attribute [initial-section] "*"
  353.  
  354.    extended-other-names := attribute other-sections "*"
  355.  
  356.    extended-initial-value := [charset] "'" [language] "'"
  357.                              extended-other-values
  358.  
  359.    extended-other-values := *(ext-octet / attribute-char)
  360.  
  361.    ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
  362.  
  363.    charset := <registered character set name>
  364.  
  365.    language := <registered language tag [RFC-1766]>
  366.  
  367.    The ABNF given in RFC 2047 for encoded-words is:
  368.  
  369.    encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
  370.  
  371.    This specification changes this ABNF to:
  372.  
  373.    encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
  374.  
  375.  
  376. 8.  Character sets which allow specification of language
  377.  
  378.    In the future it is likely that some character sets will provide
  379.    facilities for inline language labelling. Such facilities are
  380.    inherently more flexible than those defined here as they allow for
  381.    language switching in the middle of a string.
  382.  
  383.    If and when such facilities are developed they SHOULD be used in
  384.    preference to the language labelling facilities specified here. Note
  385.    that all the mechanisms defined here allow for the omission of
  386.    language labels so as to be able to accomodate this possible future
  387.    usage.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Freed & Moore               Standards Track                     [Page 7]
  395.  
  396. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  397.  
  398.  
  399. 9.  Security Considerations
  400.  
  401.    This RFC does not discuss security issues and is not believed to
  402.    raise any security issues not already endemic in electronic mail and
  403.    present in fully conforming implementations of MIME.
  404.  
  405. 10.  References
  406.  
  407.    [RFC-822]
  408.       Crocker, D., "Standard for the Format of ARPA Internet Text
  409.       Messages", STD 11, RFC 822, August 1982.
  410.  
  411.    [RFC-1766]
  412.       Alvestrand, H., "Tags for the Identification of Languages", RFC
  413.       1766, March 1995.
  414.  
  415.    [RFC-2045]
  416.       Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  417.       Extensions (MIME) Part One: Format of Internet Message Bodies",
  418.       RFC 2045, Innosoft, First Virtual Holdings, December 1996.
  419.  
  420.    [RFC-2046]
  421.       Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  422.       Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft,
  423.       First Virtual Holdings, December 1996.
  424.  
  425.    [RFC-2047]
  426.       Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
  427.       Three: Representation of Non-ASCII Text in Internet Message
  428.       Headers", RFC 2047, University of Tennessee, December 1996.
  429.  
  430.    [RFC-2048]
  431.       Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail
  432.       Extensions (MIME) Part Four: MIME Registration Procedures", RFC
  433.       2048, Innosoft, MCI, ISI, December 1996.
  434.  
  435.    [RFC-2049]
  436.       Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  437.       Extensions (MIME) Part Five: Conformance Criteria and Examples",
  438.       RFC 2049, Innosoft, FIrst Virtual Holdings, December 1996.
  439.  
  440.    [RFC-2060]
  441.       Crispin, M., "Internet Message Access Protocol - Version 4rev1",
  442.       RFC 2060, December 1996.
  443.  
  444.    [RFC-2119]
  445.       Bradner, S., "Key words for use in RFCs to Indicate Requirement
  446.       Levels", RFC 2119, March 1997.
  447.  
  448.  
  449.  
  450. Freed & Moore               Standards Track                     [Page 8]
  451.  
  452. RFC 2184    MIME Parameter Value and Encoded Word Extensions August 1997
  453.  
  454.  
  455.    [RFC-2130]
  456.       Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
  457.       R., Crispin, M., Svanberg, P., "Report from the IAB Character Set
  458.       Workshop", RFC 2130, April 1997.
  459.  
  460.    [RFC-2183]
  461.       Troost, R., Dorner, S., and Moore, K., "Communicating Presentation
  462.       Information in Internet Messages:  The Content-Disposition
  463.       Header", RFC 2183, August 1997.
  464.  
  465. 11.  Authors' Addresses
  466.  
  467.    Ned Freed
  468.    Innosoft International, Inc.
  469.    1050 East Garvey Avenue South
  470.    West Covina, CA 91790
  471.    USA
  472.     tel: +1 818 919 3600           fax: +1 818 919 3614
  473.     email: ned@innosoft.com
  474.  
  475.    Keith Moore
  476.    Computer Science Dept.
  477.    University of Tennessee
  478.    107 Ayres Hall
  479.    Knoxville, TN 37996-1301
  480.    USA
  481.     email: moore@cs.utk.edu
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Freed & Moore               Standards Track                     [Page 9]
  507.  
  508.