Notifications and Acknowledgements Requirements (notary) -------------------------------------------------------- Charter Last Modified: 06/05/2000 Current Status: Concluded Working Group Chair(s): Ned Freed Harald Alvestrand Applications Area Director(s): Ned Freed Patrik Faltstrom Applications Area Advisor: Ned Freed Technical Advisor(s): John Klensin Mailing Lists: General Discussion:notifications@cs.utk.edu To Subscribe: notifications-request@cs.utk.edu Archive: Description of Working Group: The purpose of the NOTARY Working Group is to give the Internet e-mail user better tools to build a system where the sender of a message can find out what happened to it. Work items for this group: - Specify a reporting format that can be used for delivery, non-delivery and receipt reports. The format should conform to MIME, and be at least as informative as current examples of non-standardized non-delivery notifications. This format should be usable as-is in current e-mail products to replace the current, non-standardized and sometimes quite cryptic textual non-delivery reports. The drafts by Keith Moore and Greg Vaudreuil are taken as a working basis. (See the document list below for details.) - Specify a way for the sender to request that positive delivery reports be generated for a message sent via SMTP. The draft by Keith Moore is taken as a working basis. - Generate an Informational document that gives advice on how to handle delivery notifications (positive and negative) and requests for them at boundaries to other mail systems, such as X.400 and PC LANs. Relationship to X.400 and X.400 gateways: While the intent of this work includes specification of an acknowledgement system that can be translated to work across the 821/822/MIME to X.400 boundary, the effort will focus on design from the former standpoint. That will be followed by changes to the successor of RFC 1327 to match these features, but those changes will be made as part of the RFC 1327 revision process, not by this working group. Of course, if any features specified by this working group turn out to be impossible to accomodate in the RFC 1327 revision, that would be cause for reviewing both sets of specifications. Additional items not on the agenda of this working group: - Specification of a way in which the sender can request that a receipt notification (``the recipient has read this message'') be sent upon receipt of the message. The document should identify the controversial aspects of such a function, and should attempt to specify the function in a way that minimizes surprise at both the sending and receiving end, even in the face of varying local policies. However, the group will, as part of its work, make a recommendation to the IESG where and how such work should be tackled. Goals and Milestones: APR 94 Release Request mechanism document as an Internet-Draft. APR 94 Submit notification document to IESG for consideration as a Proposed Standard. APR 94 Release Gateway Advice document as an Internet-Draft. JUL 94 Submit Gateway Advice document for publication as an Informational RFC. JUL 94 Submit Request Mechanism document to IESG for consideration as a Proposed Standard. Internet-Drafts: No Current Internet-Drafts. Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC1894 PS JAN 96 An Extensible Message Format for Delivery Status Notifications RFC1891 PS JAN 96 SMTP Service Extension for Delivery Status Notifications RFC1892 PS JAN 96 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages RFC1893 PS JAN 96 Enhanced Mail System Status Codes