One document matched: draft-ietf-notary-mime-report-01.txt

Differences from draft-ietf-notary-mime-report-00.txt

     Network Working Group                         Greg Vaudreuil
     Internet Draft                        Octel Network Services
     Expires: July 16, 1995                      January 16, 1995


                          The Multipart/Report Content Type
                                for the Reporting of
                         Mail System Administrative Messages

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



     Changes since last revision:

     1) Multipart/Report is required to be the outermost MIME content-type to
     facilitate automatic detection and processing by a UA via RFC 822 header
     parsing.

     2) The third section of the multipart may be any labeled MIME content-type
     necessary to return the content of the message.

     3) A new mime content type is defined for the return of the headers only in
     the third body part.  While headers are a subset of the Message/RFC822
     content-type, the semantics are different.

     1. 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".

     2. The multipart/report MIME content-type

     The multipart/report MIME content-type is a general "family" or "container"
     type for electronic mail reports of any kind. Although this memo defines
     only the use of the multipart/report content-type with respect to delivery
     status reports, mail processing programs will benefit if a single content-
     type is used to for all kinds of reports.


     Internet Draft        Multipart/Report               1/16/95


     The multipart/report content-type is defined as follows:

           MIME type name: multipart
           MIME subtype name: report
           Required parameters: boundary, report-type
           Optional parameters: none
           Encoding considerations: 7bit should always be adequate
           Security considerations: see section 7 of this memo.

     The syntax of multipart/Report is identical to the Multipart/Mixed content
     type defined in [3].  When used to send a report, the multipart/report
     content-type must be the top-level MIME content type for any report
     message.

          A user agents and gateways must be able to automatically determine
          that a message is a mail system report and should be processed as
          such.  Placing the multipart/report as the outermost content provides
          a mechanism whereby an auto-processor may detect through parsing the
          RFC 822 headers that the message is a report.

     The multipart/report content-type contains either two or three sub-parts,
     in the following order:

     (1) [required]  The first body part is a text/plain body part containing
        explanatory text.  This text may be in any MIME standards-track
        charset, and in any language.  The purpose of this text is to provide,
        for a human reader who may not have an user agent capable of
        interpreting a message/report, an easily-understood description of the
        condition(s) that caused the report to be generated.

        This body part may also be used to send detailed trace information that
        cannot be easily formatted into a message/report body part.

     (2) [required]  A message/report body part containing an account of the
        reported message handling event. The purpose of this body part is to
        provide a machine-readable description of the condition(s) which caused
        the report to be generated, along with details not present in the
        text/plain body part that may be useful to human experts.

     (3) [optional]  A body part containing the returned message or a portion
        thereof.  This information may be useful to aid human experts in
        diagnosing problems.  (Although it may also be useful to allow the
        sender to identify the message which the report was issued, it is hoped
        that the envelope-id and original-recipient-address returned in the
        message/report body part will replace the traditional use of the
        returned content for this purpose.)

     The Message/Report body part contains the specific service report
     information, such as error reports, read-receipts, and service reports.
     This content-type is defined in [1].

     Return of content may be wasteful of network bandwidth and a variety of
     implementation strategies can be used.  Generally the sender should choose
     the appropriate strategy and inform the recipient of the required level of

     Vaudreuil          Expires July 16, 1995            [Page 2]


     Internet Draft        Multipart/Report               1/16/95


     returned content required.  In the absence of an explicit request for level
     of return of content such as that provided in [5], the agent which
     generated the delivery service report should return the full message
     content.

        The Message/RFC822-Headers MIME content-type     3. 

     The Message/RFC822-Headers MIME content-type provides a mechanism to label
     and return only the headers of a failed message.  These headers are not the
     complete message and should not be returned as a Message/RFC822.  The
     returned headers are useful for correlating the erred message and for
     diagnostics based on the received-from: lines.

     The Message/RFC822-Headers content-type is defined as follows:

           MIME type name: Message
           MIME subtype name: RFC822-Headers
           Required parameters: None
           Optional parameters: none
           Encoding considerations: 7 bit is sufficient
           Security considerations: see section 7 of this memo.

     The message/RFC822-headers body part must contain all the RFC822 header
     lines from the message which caused the report.

        References     4. 

     [1] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery
     Status Reports", Internet-Draft.

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

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

        Security Consideration     5. 

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

     6. Author's Address

     Gregory M. Vaudreuil
     Octel Network Services
     17060 Dallas Parkway
     Dallas, TX 75248-1905
     Greg.Vaudreuil@ONS.Octel.com





     Vaudreuil          Expires July 16, 1995            [Page  ]                                                               3