wdiff draft-vaudreuil-1892bis-01.txt draft-vaudreuil-1892bis-02.txt

Internet Draft Greg Vaudreuil
ExpiresA new Request for Comments is now available in six months Lucent Technologies
April 16, 2002 online RFC libraries.

RFC 3462

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

<draft-vaudreuil-1892bis-01.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft is in conformance with Section 10 of RFC 2026.

Abstract
Author(s): G. Vaudreuil
Status: Standards Track
Date: Janaury 2003
Mailbox: GregV@ieee.org
Pages: 7
Characters: 12186
Obsoletes: 1892

I-D Tag: draft-vaudreuil-1892bis-02.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3462.txt

The Multipart/Report MIME Multipurpose Internet Mail Extensions (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.

This document is part of a four document set describing the delivery
status report service. This collection includes the SMTP Simple Mail
Transfer Protocol (SMTP) extensions to request delivery status
reports, a MIME content for the reporting of delivery reports, an
enumeration of extended status codes, and this
document describing a multipart container for
the delivery report, the original message, and a human-friendly
summary of the failure.

Working Group Summary

RFC 1892 was a product of the Notary working group.

This document is now a revision of that document providing clarifications as necessary to
advance to draft standard.

Document Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Proposed Standard Protocol.

This document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

1. THE MULTIPART/REPORT CONTENT TYPE.................................3
2. THE TEXT/RFC822-HEADERS...........................................4
3. SECURITY CONSIDERATIONS...........................................5
4. REFERENCES........................................................5
5. COPYRIGHT NOTICE..................................................6
6. AUTHOR'S ADDRESS..................................................6
APPENDIX A - CHANGES FROM RFC1893....................................7

1. The Multipart/Report Content Type

The Multipart/Report MIME content-type is a general "family" or
"container" type specifies an Internet standards track protocol 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 Internet community, and requests discussion and suggestions
for all kinds of reports.

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 4 of this memo.

The syntax of Multipart/Report is identical improvements. Please refer to the Multipart/Mixed
content type defined in [MIME]. When used to send a report, the
Multipart/Report content-type must be the top-level MIME content type
for any report message. The report-type parameter identifies the type
of report. The parameter is the MIME content sub-type of the second
body part current edition of the Multipart/Report.

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:
"Internet Official Protocol Standards" (STD 1) [Required] The first body part contains human readable message. The
purpose of this message is to provide an easily understood description
of the condition(s) that caused the report to be generated, for a
human reader who may not have an user agent capable of interpreting the second section
standardization state and status of the Multipart/Report.

The text in the first section may be in any MIME standards-track
content-type, charset, or language. Where a description this protocol. Distribution
of the error this memo is desired in several languages or several media, a
Multipart/Alternative construct may be used. unlimited.

This body part may also be used to send detailed information that
cannot be easily formatted into a Message/Report body part.

(2) [Required] A machine parsable body part containing an account of
the reported message handling event. The purpose of this body part announcement is sent to provide a machine-readable description of the condition(s) that
caused IETF list and the report RFC-DIST list.
Requests to be generated, along with details not present in
the first body part that may be useful added to human experts. An initial
body part, Message/delivery-status is defined in [DSN]
(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 deleted from the IETF distribution list
should be useful sent to allow the
sender IETF-REQUEST@IETF.ORG. Requests 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.)

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 returned content required. In the absence of an
explicit request for level of return of content such as that provided
in [DRPT], the agent that generated
added to or deleted from the delivery service report RFC-DIST distribution list should
return the full message content.

When data not encoded in 7 bits is to
be returned, and the return path
is not guaranteed sent to be 8-bit capable, two options are available. The
original message MAY be re-encoded into a legal 7-bit MIME message RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or
the Text/RFC822-Headers content-type MAY EMAIL may be used to return only the
original obtained by sending
an EMAIL message headers.

2. The Text/RFC822-Headers content-type

The Text/RFC822-Headers MIME content-type provides a
mechanism to label and return only the RFC 822 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 identifying rfc-info@RFC-EDITOR.ORG with the
failed message and for diagnostics based on the received:
lines.

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

MIME type name: Text
MIME subtype name: RFC822-Headers
Required parameters: None
Optional parameters: none
Encoding considerations: 7 bit is sufficient for normal RFC822
headers, however, if the headers are broken and require
encoding to make them legal 7 bit content, they may be
encoded in quoted-printable.
Security considerations: see section 3 of this memo.

The Text/RFC822-headers body part
help: ways_to_get_rfcs. For example:

To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should contain all the RFC822 header
lines from the message which caused the report. The RFC822 headers
include all lines prior be addressed to either the blank line in the message. They include
the MIME-Version and MIME Content- headers.

3. Security Considerations

Automated use of report types without authentication presents several
security issues. Forging negative reports presents the opportunity
for denial-of-service attacks when the reports are used for automated
maintenance of directories or mailing lists. Forging positive reports
may cause the sender to incorrectly believe a message was delivered
when it was not

4. References

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.

[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, University
author of Tennessee,
Octel Network Services, January 1996.

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

[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, June 1992.

[DRPT] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, University of Tennessee, January 1996.

5. Copyright Notice

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice question, or references to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the Internet Society or other
Internet organizations, except as needed RFC itself, all RFCs are for the purpose of developing
Internet standards in which case the procedures
unlimited distribution.echo
Submissions for copyrights defined
in the Internet Standards process MUST Requests for Comments should be followed, or as required sent to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

6. Author's Address

Gregory M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, TX 75248-1905
Voice/Fax: +1-972-733-2722
GregV@ieee.org

Appendix A - Changes from RFC1892

Changed Authors contact information

Updated required standards boilerplate

Edited the text
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to make it spell-checker and grammar checker compliant RFC
Authors, for further information.