Updated Implementation Report posted June 17, 2003 (former Report follows this update) IETF Applications Area Message Disposition Notification Interoperability Report Greg Vaudreuil / Lucent Technologies The VPIM working group is again requesting that the Message Disposition Notification protocol be promoted to Draft Standard. The MDN protocol specification documented in RFC 2298 has seen widespread implementation and deployment. Several desktop clients send MDN requests and generate MDN responses. Fewer interpret the MDN responses in a machine fashion. VPIM and iFAX systems do interpret the MDN reports. Many options defined in RFC 2298 have not seen implementation or deployment and have been removed from the current draft. As such, the following changes have been made in : 1) The dispositions "denied", and "failed" were removed from the document reflecting the lack of implementation or usage at this time. 2) The disposition modifiers "warning", "superseded", "expired", and "mailbox-terminated" have not seen actual implementation and have been deleted from the draft. The extension modifier, while not currently used, has been retained for future extensibility. 3) General editorial cleanups include spelling, grammar, and consistency in usage of terms. The MDN specification has been implemented by a number of VPIM vendors, including Comverse, Lucent, and Nortel. These implementations request, generate an MDN report, and machine interpret the result and render the report to the user in the form of a spoken notification. General implementation results including MDN testing are posted on http://www.vpim.org/vpim. The specification is also implemented by several simple mode fax vendors including Cisco, Ricoh, and Sharp. These implementations request an MDN and generate a report. The fax vendors generally render the report to the sender as uninterpreted text. Various desktop clients have implemented MDN including Netscape messenger, Qualcomm Eudora, Microsoft Outlook, and Exmh. These clients generally support the request for an MDN, generate a MDN report, and present the MDN report to the user. The MDN report is presented as a text item and not machine interpreted for richer presentation to the end user. Detailed implementation reports have been provided by Ned Freed for the SunOne message server, Simon Josefsson for the Gnus MUA, and Greg Vaudreuil for the MessagingLink gateway. Earlier reports were collected from the MUA vendors immediately following the London IETF (July/August 2001) from several iFAX and VPIM vendors and from third party testing of popular MUA's. The results of which were used to prune the list of options in the current internet-draft version of the MDN protocol and to create an earlier implementation report for MDN. Regretfully, these original implementation reports were lost and replacement, implementation reports were not received from these vendors in response to a second call for implementation reports on the IETF mailing list. The three detailed reports received are summarized below. 1) Date Implemented and released: SunOne: Feature implemented over several releases, report for current release. Gnus, v0.05, January 2002 MessagingLink 2.1, 2000 2) MDN Requesting Behavior a) Client sends disposition-notification-to header: (Y/N) The Messenger Express client component of SunOne message server has the ability to do this. Guns requests the header. MessagingLink converts a request for MDN in the OctelNet protocol to this header when acting as a gateway. b) Client sends disposition-notifications-options header (Y/N) b1) Client sends request for proprietary options (describe) No implementations reported requesting proprietary options extension headers. c) Message disposition header is placed in inner message when used with message partial (Y/N/NA) Please indicate N/A if the UA or gateway does not generate message partial constructs SunOne message server does this when messages are fragmented. The opposite is also true: These fields are copied from the inner message to the new message while defragmenting. Gnus and MessagingLink do not fragment nor reassemble messages. 3) Final MTA behaviors a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO command into Original-Recipient header of message upon deposit SunOne does this as long as the number and nature of the recipients permit it. This behavior is not applicable to Gnus or MessagingLink. Neither is responsible for final delivery. 4) MDN Generating UA a) MDN report is generated upon request (Y/N). If yes, which fields are populated: Reporting-UA mdn-gateway-field original-recipient-field final-recipient-field original-message-id-field disposition-field failure-field error-field warning-field extension-field SunOne provides facilities for generating MDNs with all of these fields are built in to the product. However, at present the two primary uses are: (1) Displayed MDNs are generated by Messenger Express, which only produces final-recipient-field, original-message-id-field, and disposition-field. (2) Deleted MDNs are generated by the reject sieve action, which only produces original-recipient-field, final-recipient-field, original-message-id-field, and disposition-field. Gnus does not generate MDN's. MessagingLink provides the following fields when converting from OctelNet, mdn-gateway, final-recipient, and disposition-field. b) Which disposition modes are supported / generated: Manual action automatic action MDN-sent-manually MDN-sent-automatically SunOne generated all these modes in practice. Gnus does not generate MDNs. MessagingLink generates only manual action, MDN-sent-automatically, corresponding to the semantics of an OctelNet MDN. c) Which disposition types are generated displayed deleted SunOne generates both displayed and deleted types. Gnus does not generate MDN's. MessagingLink generates both displayed and deleted disposition types. d) Are any extension fields generated? No implementations reported generating extension fields. 5) MDN receiving user agent behavior a) Which of the following fields are presented to the user or converted into a foreign format via gateway Reporting-UA mdn-gateway-field original-recipient-field final-recipient-field original-message-id-field disposition-field failure-field error-field warning-field extension-field SunOne all of these fields can be displayed in the text of the MDN. Guns displays all fields a text. MessagingLink converts the final recipient and disposition fields into the relevant OctelNet protocol elements. 6) Interoperability Experience No known problems were reported. ___________________________________________________________________________ Former Implementation Report: Implementation Report for Message Disposition Notifications (MDNs) moving to Draft Standard MDN implementation breaks down into three separate areas: (1) Client support for sending MDN requests. (2) Client support for acting on MDN requests and sending MDNs. (3) Client support for rendering of MDNs. These numbers will be used as labels throughout this report. It is important to note that MDNs are a client to client protocol; apart from transporting MDN request headers and MDN messages, message submission, transfer, and delivery agents are not involved in the implementation of MDN. MDN request headers and MDN messages are designed so that any message submission, transfer, or delivery implementation that complies with the associated messaging standards (RFC 822, SMTP, ESMTP, and MIME) can be used. It is also important to note that MDNs are constructed as MIME multipart objects. This means that any agent that conforms to the MIME specification is capable of displaying an MDN in a reasonable fashion. Several desktop clients send MDN requests (1) and generate MDNs (2). Fewer interpret the MDNs in a mechanical fashion (3). VPIM systems and desktop messaging clients do interpret MDNs, although the extent to which they do so varies. However, many specific MDN options defined in RFC 2298 have not seen implementation or deployment and have been removed from the current draft: The dispositions "denied", and "failed" were removed from the document reflecting the lack of implementation or usage at this time. The disposition modifiers "warning", "superseded", "expired", and "mailbox-terminated" have not seen actual implementation and have been deleted from the draft. The extension modifier, while not currently used, has been retained for future extensibility. The MDN specification has been implemented by a number of VPIM vendors, including Comverse, Lucent, and Nortel. These implementations request MDNs (1), generate MDNs (2), and machine interpret MDNs and render MDNs for the user (3). The specification is also implemented by several simple mode fax vendors including Cisco, Ricoh, and Sharp. These implementations generate MDN requests (1) and generate MDNs in response to MDN requests (2), but generally display MDNs as uninterpreted text. Various desktop clients have implemented MDN, including Netscape Messenger, Qualcomm Eudora, Microsoft Outlook, and Exmh. These clients are all capable of generating MDN requests (1) and generate MDNs in response to such requests (2). These clients all rely on their ability to render MIME messages in order to display MDNs; they do not implement MDN-specific handling (3). Finally, the message format validator operated by the applications area available at: http://www.apps.ietf.org/msglint.html validates both MDN request headers (1) and MDNs themselves (3).