Network Working Group                         Greg Vaudreuil
     Internet Draft                        Octel Network Services
     Expires: 1-25-95                              August 1, 1994
                                  Multipart/Report

                       <draft-ietf-notary-mime-report-00.txt>



     Status of this Memo

     This document is an Internet Draft.  Internet Drafts are working documents
     of the Internet Engineering Task Force (IETF), its Areas, and its Working
     Groups.  Note that other groups may also distribute working documents as
     Internet Drafts.

     Internet Drafts are valid for a maximum of six months and may be updated,
     replaced, or obsoleted by other documents at any time.  It is inappropriate
     to use Internet Drafts as reference material or to cite them other than as
     a "work in progress".

     1. Introduction

     This memo defines a generic packaging mechanism for mail system reports.
     The Multipart/Report is a convention for interpersonal message
     notifications for MIME.

     2. Multipart/Report

     Mime type name: Multipart
     Mime Sub-Type name: Report
     Required Parameters: Boundary, Report-type
     Optional Parameters: None
     Encoding Considerations: 7bit should always be adequate.

     The syntax of a Multipart/Report is identical to the Multipart\Mixed
     content type.  The Report may contain up to three body parts.  The
     Multipart/Report must always be the outer-most MIME content.  The semantics
     of a Multipart/Report which is not the outermost content type such as a
     forwarded Multipart/Report are undefined.  The report-type parameter
     indicates the type of Report.  Expected Report types include delivery
     status and read receipts.

          The Multipart/Report is required to be the outermost content type so
          that existing final delivery agents which can route messages based on
          RFC 822 heasder fields may detect the multipart/report header and
          provide automated processing of reports.

     The first body part is intended to be a single text/plain or
     multipart/alternative set of text/plain body parts describing the report in
     human readable form.  This text may be in any character set or language as
     appropriate for the environment.

     The second body part is a machine parseable description of the Report such
     as a message/delivery-report.  This body part is described in a separate
     document and is indicated by the Report-type parameter.  If the delivery


     Internet Draft        Multipart/Report        August 1, 1994


     report is to be privacy enhanced, this body part may be packaged in a a
     multi-part security content.

          Note that multipart security body parts which operate on the entirity
          of the multipart/report will violate the reqirement that the
          multipart/report be the top-level content-type on the message.

     The third body part may be of any content-type and contains the returned
     message for which the delivery report is defined. This may include
     Message/RFC822 but is not restricted to be such.

        References     3. 

     [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages",
     STD 11, RFC 822, UDEL, August 1982.

     [2] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", RFC
     1341, Bellcore, Innosoft, June 1992.

     [3] Moore, K., Vaudreuil, G.,  An Extensible Message Format for Delivery                                   ``
     Status Reports''                    , Internet-Draft, Work In Progress.

     4. Security Consideration

     Multipart/Report introduces no security threats beyond those already
     present in Internet mail.  Automated use of report types without
     authentication may present opportunities for denial-of-service attacks.

     5. Author's Address

     Gregory M. Vaudreuil
     Octel Network Services
     17080 Dallas Parkway
     Dallas, TX 75248-1905
     USA
     Greg.Vaudreuil@Octel.Com