The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
RFC 6522

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt)

The IESG has approved the following document:
- 'The Multipart/Report Media Type for the Reporting of Mail System
   Administrative Messages'
  (draft-ietf-appsawg-rfc3462bis-04.txt) as a Full Standard

This document is the product of the Applications Area Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3462bis/


Technical Summary 

The multipart/report media 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 media type with respect to delivery status 
reports, mail processing programs will benefit if a single media type is 
used for all kinds of reports. 

Practical experience has shown that the general requirement of having 
that media type constrained to be used only as the outermost MIME 
type of a message, while well-intentioned, has provided little operational 
benefit and actually limits such things as the transmission of multiple 
administrative reports within a single overall message container. In 
particular, it prevents one from forwarding a report as part of another 
multipart MIME message. 

This update removes that constraint. No other changes apart from 
some editorial ones are made. 

Working Group Summary 

There was initially concern that the original requirement that multipart/report 
be a top-level-only media type was done for a good reason, and that the 
requirement should not be removed entirely. After some discussion, it seemed 
that the right approach was to retain the requirement in the context of newly 
generated DSNs, but to lift it in the more general case. This version of the 
document does just that, by reference to the original DSN specifications, and 
that formulation has broad consensus. 

Document Quality 

Multipart/report is very widely implemented and deployed, and, in fact, it has 
been used in the form described herein, with the top-level constraint ignored, 
for years. Ned Freed, who is the expert reviewer for media types, has reviewed 
this update and is happy with it. The interoperability report that was used to
take 3462 to Draft was:
http://www.ietf.org/iesg/implementation/report-rfc1891-1894.txt

Personnel

Barry Leiba <barryleiba@computer.org> is the Document Shepherd.
Pete Resnick <presnick@qualcomm.com> is the AD.