Network Working Group G. Vaudreuil Request for Comments: 1892 Octel Network Services Category: Standards Track January 1996
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 to the Multipart/Mixed
content type defined in
RFC 1521 [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 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:
The text in the first section may be in any MIME standards-track content-type, charset, or language. Where a description of the error is desired in several languages or several media, a Multipart/Alternative construct may be used.
This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report body part.
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 which generated the delivery service report should return the full message content.
When data not encoded in 7 bits is to be returned, and the return path is not guaranteed to be 8-bit capable, two options are available. The origional message MAY be reencoded into a legal 7 bit MIME message or the Text/RFC822-Headers content-type MAY be used to return only the origional message headers.
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, they may be encoded in quoted-printable.
Security considerations: see section 4 of this memo.
The Text/RFC822-headers body part should contain all the RFC822
header lines from the message which caused the report. The RFC822
headers include all lines prior to the blank line in the message.
They include the MIME-Version and MIME Content- headers.