The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.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 <email@example.com> is the Document Shepherd. Pete Resnick <firstname.lastname@example.org> is the AD.