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.