home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1428 < prev    next >
Text File  |  1993-02-10  |  12KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Vaudreuil
  8. Request for Comments: 1428                                          CNRI
  9.                                                            February 1993
  10.  
  11.  
  12.                    Transition of Internet Mail from
  13.                               Just-Send-8
  14.                            to 8bit-SMTP/MIME
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC provides information for the Internet community.  It does
  19.    not specify an Internet standard.  Distribution of this memo is
  20.    unlimited.
  21.  
  22. Abstract
  23.  
  24.    Protocols for extending SMTP to pass 8bit characters have been
  25.    defined [3] [4]. These protocols require that messages transported by
  26.    the extended SMTP are to be encoded in MIME [1] [2].  Before work
  27.    began on these protocols, several SMTP implementations adopted ad-hoc
  28.    mechanisms for sending 8bit data. It is desirable for the extended
  29.    SMTP environment and these ad hoc mechanisms interoperate.  This
  30.    document outlines the problems in this environment and an approach to
  31.    minimizing the cost of transition from current usage of non-MIME 8bit
  32.    messages to MIME.
  33.  
  34. 1. Terminology
  35.  
  36.    RFC 821 defines a 7bit transport.  A transport agent which does not
  37.    clear the high order bit upon receipt of octets with this bit set in
  38.    SMTP messages is called 8 bit transparent in this document. An
  39.    implementation of the general SMTP Extensions document [3] and the
  40.    8bit extensions protocol [4] which passes MIME messages using all 8
  41.    bits of an octet is called 8bit ESMTP.  An implementation of extended
  42.    SMTP which does not accept 8bit characters is called 7bit ESMTP.  A
  43.    gateway is defined to be a transport agent with User Agent authority
  44.    to alter or convert the content of a message.
  45.  
  46. 2. The Problem
  47.  
  48.    SMTP as defined in RFC 821 limits the sending of Internet Mail to
  49.    US-ASCII [5] characters.  As the Internet has grown to include non-
  50.    English correspondents, the need to communicate with character sets
  51.    other than US-ASCII has prompted many vendors and users to extend
  52.    SMTP or RFC 822 to use non-ASCII character sets.  Common approaches
  53.    are to send 7 bit national variant ISO 646 character sets over
  54.    current RFC822/SMTP, to extend SMTP and RFC822 to use 8bit ISO 8859
  55.  
  56.  
  57.  
  58. Vaudreuil                                                       [Page 1]
  59.  
  60. RFC 1428              Transition to 8bit-SMTP/MIME         February 1993
  61.  
  62.  
  63.    character sets, and to use proprietary PC character sets.
  64.  
  65.    A third approach is used for Japanese mail.  Japanese characters are
  66.    represented by pairs of octets with the high order bit cleared.
  67.    Switching between 14 bit character sets and 7 bit character sets is
  68.    indicated within the message by ISO 2022 escape sequences.
  69.  
  70.    So long as these implementations can communicate without intermediate
  71.    transformations and have a loose private agreement on the use of a
  72.    specific character set without tagging, basic mail service can be
  73.    provided.
  74.  
  75.    In the transition to the negotiated 8bit ESMTP/MIME environment, it
  76.    is important that mail sent by a currently non-conforming user can be
  77.    read by another non-conforming user.  This existing functionality is
  78.    reduced by conversion from 8bit text to text encoded in unreadable
  79.    Base-64 or "garbled" text encoded in quoted printable.
  80.  
  81.    There are several interesting non-interoperable cases that currently
  82.    exist in non US-ASCII mail and several new ones likely to emerge in a
  83.    transition to 8bit/MIME.  Below is a listing of the transition-to-
  84.    mime cases.  Only solutions to (4) in the context of a translating
  85.    gateway are discussed in this memo.
  86.  
  87.                 \ Receiver
  88.                   \    7bit     8bit          MIME/
  89.              Sender \| only   | transparent | ESMTP
  90.            ----------------------------------------
  91.            7bit only |  (1)   |    (1)      | (1)
  92.            ----------------------------------------
  93.     8bit transparent |  (2)   |    (3)      | (4)
  94.            ----------------------------------------
  95.           MIME/ESMTP |  (5)   |    (5)      | (6)
  96.  
  97.  
  98.    (1) 7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver
  99.  
  100.       This will continue to work unchanged with nationally varient ISO
  101.       646 or ISO 2022 character set shifting if an external "out of
  102.       band" agreement exists between the sender and the receiver.  A
  103.       7bit to 8bit/ESMTP gateway need not alter the content of this
  104.       message.
  105.  
  106.    (2) 8bit sender to 7bit non-MIME receiver
  107.  
  108.       The receiver will receive bit-stripped mail which results in the
  109.       mis-interpretation of the data and the wrong character being
  110.       displayed or printed.  Mail sent using languages where most
  111.  
  112.  
  113.  
  114. Vaudreuil                                                       [Page 2]
  115.  
  116. RFC 1428              Transition to 8bit-SMTP/MIME         February 1993
  117.  
  118.  
  119.       characters are in the US-ASCII subset of ISO 8859 may be somewhat
  120.       readable.
  121.  
  122.    (3) 8bit transparent sender to 8bit transparent receiver
  123.  
  124.       Will work if an external agreement "out of band" to use a
  125.       particular character set without tagging exists between the sender
  126.       and the receiver.
  127.  
  128.    (4) 8bit transparent sender to MIME/ESMTP conformant receiver
  129.  
  130.       Will work if a reasonable upgrade path is provided via gateways,
  131.       the indicated character set tag inserted by the gateway is correct
  132.       and the receiver supports the character set chosen by the sender.
  133.       This case is the focus of this memo.
  134.  
  135.    (5) MIME/ESMTP sender to non-MIME 7bit receiver
  136.  
  137.       Because the ESMTP/MIME sender cannot know if the receiver will
  138.       understand 8bits, the sender will encode the text into base-64 or
  139.       quoted-printable which may be considered "garbled" by the
  140.       receiver.  To provide a useful downgrade path the gateway must
  141.       have some knowledge about the capabilities of the receiver. When
  142.       the character set can be clearly identified, techniques like the
  143.       menmonic MNEM encoding described in RFC 1345 may be helpful in
  144.       this case.
  145.  
  146.    (6) MIME/ESMTP sender to MIME/ESMTP receiver
  147.  
  148.       Interoperability will be attained provided the receiver supports
  149.       the character set chosen by the sender.
  150.  
  151. 3. Upgrade Path from 8bit Transparent to ESMTP/MIME
  152.  
  153.    A gateway which has been upgraded to support Extended SMTP may
  154.    upgrade an 8bit message received to MIME.  This is consistent with
  155.    the requirement that all 8bit mail sent by ESMTP be encoded in MIME.
  156.    The upgrade should be done using the best available information.
  157.  
  158.    A site may "upgrade" to MIME en-masse by implementing MIME conversion
  159.    for all messages leaving the site.  For text messages, the body can
  160.    be converted by adding a MIME-version header and a Content-Type:
  161.    Text/Plain with the character set in use in the site, provided the
  162.    site uses a single character set.
  163.  
  164.    An appropriate Content-Transfer-Encoding header line must be added to
  165.    indicate any encoding that may be necessary.
  166.  
  167.  
  168.  
  169.  
  170. Vaudreuil                                                       [Page 3]
  171.  
  172. RFC 1428              Transition to 8bit-SMTP/MIME         February 1993
  173.  
  174.  
  175.     Example:
  176.  
  177.        MIME-Version: 1.0
  178.        Content-Type: Text/Plain; Charset = ISO-8859-1
  179.        Content-Transfer-Encoding: 8bit
  180.  
  181.    If no information about the character set in use is available, the
  182.    gateway should upgrade the content by using the character set
  183.    "unknown-8bit". The unknown-8bit value of the charset parameter
  184.    indicates only that no reliable information about the character
  185.    set(s) used in the message was available.
  186.  
  187.    If a message body has been upgraded to MIME, the RFC 822 headers
  188.    containing non US-ASCII characters must be upgraded to conform with
  189.    the header encoding rules of RFC1342. A gateway should recode all
  190.    unstructered header fields as well as RFC 822 "comment"s and
  191.    "phrase"s according to the rules of RFC 1342. There is no equivalent
  192.    in RFC 1342 to the "8bit" Content-Transfer-Encoding value for message
  193.    bodies so all 8bit header text must be transformed according to
  194.    either the "B" or the "Q" encoding method.  For ISO 8859 character
  195.    sets, the "Q" encoding will generally result in somewhat readable
  196.    headers.
  197.  
  198.    Trace information should be added to the document with a convert
  199.    clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-
  200.    printable" e.g.,
  201.  
  202.    Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
  203.              convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700
  204.  
  205. Appendix - The "unknown-8bit" Character Set
  206.  
  207.    This section defines a "charset" parameter, for use in a MIME
  208.    Content-Type field.
  209.  
  210.    A special purpose character set called "unknown-8bit" is defined to
  211.    be an unknown 8bit character set, encoded into a sequence of octets.
  212.    It can be used as a label for any character set from any language,
  213.    using any encoding.  It must not be further defined.
  214.  
  215.    The use of this token in a "charset=" field of a message indicates
  216.    that nothing is known about the character set used. This marker is
  217.    intended for use by non-MIME to MIME gateways; specifically in those
  218.    which translate from SMTP to 8bit ESMTP/MIME.
  219.  
  220.    This character set is not intended to be used by mail composers.  It
  221.    is assumed that the mail composer knows the character set in use and
  222.    will mark it with a character set value as specified in [1], as
  223.  
  224.  
  225.  
  226. Vaudreuil                                                       [Page 4]
  227.  
  228. RFC 1428              Transition to 8bit-SMTP/MIME         February 1993
  229.  
  230.  
  231.    amended by current Assigned Numbers documents [6].
  232.  
  233.    The use of the "unknown-8bit" label is intended only by mail gateway
  234.    agents which cannot determine via out-of-band information the
  235.    intended character set.
  236.  
  237.    The interpretation of the "unknown-8bit" is up to the mail reader.
  238.    It is assumed that in many cases the human user will be able to
  239.    interpret the information and choose an appropriate character set or
  240.    pre-processor.
  241.  
  242. Acknowledgements
  243.  
  244.    This document originated as a hallway conversation between Ned Freed,
  245.    Neil Katin, and the author.  Substantive input was received from
  246.    Jonathan Laventhol, Craig Everhart, Olle Jarnefors, and Olafur
  247.    Gudmundsson.  The document was refined with the input of many
  248.    participants in the IETF SMTP Extensions Working Group.
  249.  
  250. References
  251.  
  252.    [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  253.        Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
  254.  
  255.    [2] Moore, K., "Representation of Non-ASCII Text in Internet Message
  256.        Headers", RFC 1342, University of Tennessee, June 1992.
  257.  
  258.    [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
  259.        E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
  260.        Nations University, Innosoft International, Inc., Dover Beach
  261.        Consulting, Inc., Network Management Associates, Inc., The Branch
  262.        Office, February 1993.
  263.  
  264.    [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
  265.        E., and D. Crocker, "SMTP Service Extensions for 8bit
  266.        MIMEtransport", RFC 1426, United Nations University, Innosoft
  267.        International, Inc., Dover Beach Consulting, Inc., Network
  268.        Management Associates, Inc., The Branch Office, February 1993.
  269.  
  270.    [5] Coded Character Set--7-Bit American Standard Code for Information
  271.        Interchange, ANSI X3.4-1986.
  272.  
  273.    [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  274.        USC/Information Sciences Institute, July 1992.
  275.  
  276. Security Considerations
  277.  
  278.    Security issues are not discussed in this memo.
  279.  
  280.  
  281.  
  282. Vaudreuil                                                       [Page 5]
  283.  
  284. RFC 1428              Transition to 8bit-SMTP/MIME         February 1993
  285.  
  286.  
  287. Author's Address
  288.  
  289.    Greg Vaudreuil
  290.    Corporation for National Research Initiatives
  291.    1895 Preston White Drive, Suite 100
  292.    Reston, VA 22091 USA
  293.  
  294.    Phone: (703) 620-8990
  295.    EMail: GVaudre@CNRI.Reston.VA.US
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Vaudreuil                                                       [Page 6]
  339.