Newsgroups: bit.listserv.mail-l
Date:         Tue, 14 Apr 1992 12:49:48 EDT
From:         Roger Fajman <RAF@NIHCU.BITNET>
Subject: Protocol Action: Multipurpose Mail Extensions to Proposed
              Standard

== For Your Information ==

Received: from CU.NIH.GOV by NIHCU (Mailer) id 6394;
              Tue, 14 Apr 92  04:02:21 EDT
Received: from VENERA.ISI.EDU by CU.NIH.GOV
    with TCP; Tue, 14 Apr 92 4:02:15 EST
Received: by venera.isi.edu (5.65c/5.65+local-4)
       id <AA14552>; Mon, 13 Apr 1992 11:50:30 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-4)
       id <AA14405>; Mon, 13 Apr 1992 11:47:42 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa13070;
          13 Apr 92 14:42 EDT
Received: from [127.0.0.1] by ietf.NRI.Reston.VA.US id aa03848;
          13 Apr 92 14:38 EDT
From: Internet Engineering Steering Group <iesg-secretary@NRI.Reston.VA.US>
To: Bob Braden -- IAB Executive Director <braden@ISI.EDU>,
        Internet Activities Board <iab@ISI.EDU>
Cc: Internet Engineering Task Force <ietf@ISI.EDU>
Subject: Protocol Action:  Multipurpose Mail Extensions to Proposed Standard
Date: Mon, 13 Apr 92 14:38:40 -0400
Message-Id:  <9204131438.aa03848@ietf.NRI.Reston.VA.US>


Recommendation:

  The IESG recommends that the Internet Drafts "MIME (Multipurpose
  Internet Mail Extensions)" <draft-ietf-822ext-messagebodies-06>
  and "Representation of Non-ASCII Text in Internet Message Headers"
  <draft-ietf-822ext-msghead-01> jointly as a Proposed Standard. These
  documents are the product of the Internet Message Extensions Working
  Group of the IETF.

Abstract:

  These documents redefine the format of RFC 822 based messages to allow
  multi-part textual and non-textual message bodies and the use of
  non-ASCII character sets to be represented.  The mechanisms defined in
  these two documents allows the use of non-ascii text in both the
  headers and bodies of mail messages.  These changes are backward
  compatable and extend RFC 822.

Technical Summary:

 MIME
 ----

  RFC 822 defines a message representation protocol which specifies
  considerable detail about message headers, but which leaves the
  message content, or message body, as flat ASCII text.  This document
  redefines the format of message bodies to allow multi-part textual and
  non-textual message bodies to be represented and exchanged without
  loss of information.  This is based on earlier work documented in RFC
  934 and RFC 1049, but extends and revises that work.  Because RFC 822
  said so little about message bodies, this document is largely
  orthogonal to (rather than a revision of) RFC 822.

  In particular, this document is designed to provide facilities to
  include multiple objects in a single message, to represent body text
  in character sets other than US- ASCII, to represent formatted
  multi-font text messages, to represent non-textual material such as
  images and audio fragments, and generally to facilitate later
  extensions defining new types of Internet mail for use by cooperating
  mail agents.

 Message Headers
 ---------------

   MIME describes a mechanism for denoting textual body parts which
   are coded in various character sets, as well as methods for encoding
   such body parts as sequences of printable ASCII characters.  This
   memo describes similar techniques to allow the encoding of non-ASCII
   text in various portions of a RFC 822 [2] message header, in a manner
   which is unlikely to confuse existing message handling software.

   Like the encoding techniques described in MIME, the techniques
   outlined here were designed to allow the use of non-ASCII characters
   in message headers in a way which is unlikely to be disturbed by the
   quirks of existing Internet mail handling programs.  In particular,
   some mail relaying programs are known to (a) delete some message
   header fields while retaining others, (b) rearrange the order of
   addresses in To or Cc fields, (c) rearrange the (vertical) order of
   header fields, and/or (d) "wrap" message headers at different places
   than those in the original message.  In addition, some mail reading
   programs are known to have difficulty correctly parsing message
   headers which, while legal according to RFC 822, make use of
   backslash-quoting to "hide" special characters such as "<", ",", or
   ":", or which exploit other infrequently-used features of that
   specification.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU