Content-type: text/foo; charset=bar
        Content-Transfer-Encoding: base64

   must be first represented in the text/foo form, then (if necessary)
   represented in the "bar" character set, and finally transformed via
   the base64 algorithm into a mail-safe form.







 
RFC 1521                          MIME                    September 1993


Appendix H -- Changes from RFC 1341

   This document is a relatively minor revision  of  RFC  1341.  For
   the  convenience  of  those familiar with RFC 1341, the technical
   changes from that document are summarized in  this appendix.

   1.  The definition of "tspecials" has been changed to no longer
   include ".".

   2.  The Content-ID field is now mandatory for message/external-body
   parts.

   3.  The text/richtext type (including the old Section 7.1.3 and
   Appendix D) has been moved to a separate document.

   4.  The rules on header merging for message/partial data have been
   changed to treat the Encrypted and MIME-Version headers as special
   cases.

   5.  The definition of the external-body access-type parameter has
   been changed so that it can only indicate a single access method
   (which was all that made sense).

   6.  There is a new "Subject" parameter for message/external-body,
   access-type mail-server, to permit MIME-based use of mail servers
   that rely on Subject field information.

   7.  The "conversions" parameter for application/octet-stream has been
   removed.

   8.  Section 7.4.1 now deprecates the use of the "name" parameter for
   application/octet-stream, as this will be superseded in the future by
   a Content-Disposition header.

   9.  The formal grammar for multipart bodies has been changed so that
   a CRLF is no longer required before the first boundary line.

   10.  MIME entities of type "message/partial" and "message/external-
   body" are now required to use only the "7bit" transfer-encoding.
   (Specifically, "binary" and "8bit" are not permitted.)

   11.  The "application/oda" content-type has been removed.

   12.  A note has been added to the end of section 7.2.3, explaining
   the semantics of Content-ID in a multipart/alternative MIME entity.

   13.  The formal syntax for the "MIME-Version" field has been
   tightened, but in a way that is completely compatible with the only




 
RFC 1521                          MIME                    September 1993


   version number defined in RFC 1341.

   14.  In Section 7.3.1, the definition of message/rfc822 has been
   relaxed regarding mandatory fields.

   All other changes from RFC 1341 were editorial changes and do not
   affect the technical content of MIME.  Considerable formal grammar
   has been added, but this reflects the prose specification that was
   already in place.