Re: draft-vaudreuil-mdnbis-03.txt

[ned.freed@mrochek.com]

> as this is going for draft, the write-up should point to inter-op report

The template I received did not so indicate, but sure, that sounds like a fine
thing to do. Unfortunately, upon checking the implementation report page, it
seems the correct report has still not been posted despite several reqests to
do so. I am appending the correct report below my signature and I will file yet
another request with the secretariat to get the correct report put on the web
site.

				Ned

     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.

MDNs are a client to client protocol; apart from transporting MDN request
headers and MDN messages, message submission, transfer, and delivery agents are
not directly 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.

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, several 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 and render MDNs for the user [3]
in the form of a spoken notification.  General VPIM 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 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 MDNs, 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].

Detailed implementation results were provided for the revised version of the
MDN specification by Ned Freed for the SunOne Messaging Server, Simon Josefsson
for the Gnus MUA, and Greg Vaudreuil for the MessagingLink gateway. These
reports are summarized below.

Reports on the original specification were collected from MUA vendors
immediately following the London IETF (July/August 2001), from several iFAX and
VPIM vendors, and from third party testing of popular MUAs. These results 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.

--- Implementation result summary ---

(1) Date Implemented and released:

    SunOne:  Feature implemented over several releases, report for current
             release 5.2.
    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 NA 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 behavior

    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
      original-recipient
      final-recipient
      original-message-id
      disposition
      failure
      error
      warning
      extension fields

      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, original-message-id, and disposition. (2)
      Deleted MDNs are generated by the reject sieve action, which only
      produces original-recipient, final-recipient, original-message-id,
      and disposition.

      Gnus does not generate MDN's.

      MessagingLink provides the following fields when converting from
      OctelNet: mdn-gateway, final-recipient, and disposition.

  (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 and
       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

    Which of the following fields are presented to the user or converted
    into a foreign format via gateway

         Reporting-UA
         mdn-gateway
         original-recipient
         final-recipient
         original-message-id
         disposition
         failure
         error
         warning
         extension fields

    In SunOne all of these fields can be displayed in the text of the MDN.
    Facilities are also provided to do locale-specific conversion of
    field labels. Gnus displays all fields as text. MessagingLink converts
    the final recipient and disposition fields into the relevant OctelNet
    protocol elements.

(6) Interoperability Experience

    No interoperability problems were reported.