Subject: [Simple] MDN, DSN, MESSAGE and MSRP

From: "Eric Burger" <[email-masked]>
Date: Sat, 6 Mar 2004 18:51:36 -0500

Sorry I haven't been interactive in the "Advanced IM requirements" and "return receipt and delivery status notification for MSRP" threads.  Here is my collected thoughts on the subject.

First, a brief review of RFC2298 (DSN) and RFC3464 (MDN).

DSN (Delivery Status Notification) provides a mechanism for mail transfer agents (think proxy or relay) to notify a sender about problems with the forwarding of a message.

MDN (Message Disposition Notification) provides a mechanism for mail user agents (think SIP user agents) to notify a sender about the disposition (read, rejected, etc.) of a message.

Looking at the threads, it sounds like one requirement is finding out if a message made it to the user's device.

In e-mail, we address that with a DSN in the negative case.

In simple, we have two mechanisms.  First, message delivery, in both page-mode and MSRP, is reliable.  Either the message makes it to the device (200 OK) or it does not ([45]xx).  There is no need for a DSN on rejection -- the simple machinery takes care of that for us.

What happens if we get a 202?  In this case, the message is queued for delivery.  In e-mail, one can get a DSN, usually after a (reasonably long) period of time, like a day.  This avoids lots of "the message is queued; oops, I meant I just delivered it" messages.

It would be reasonable to emit something like a DSN ("message queued for a while") for IM.  We can be proactive and let the client specify a parameter for how long to wait (subject to server limitations).

Note that if the queued message gets dropped because the relay decides it will never delivery the message, a DSN, and not a MDN, gets generated (if requested).

MDNs describe what the UAS actually does with the message.  I assert (and would like list discussion) the following:

      The UAS generates a MDN (by request and with user authorization) upon
      the reading of a message ("Read Receipt").

Note the sender knows the message made it to the UAS, because they did not receive a DSN.

Is it desirable and, in the real world, useful, to have a "Deleted" MDN?  While it is defined for e-mail, people rarely use it.  When most messages get deleted without being read, the user often denies sending MDN's.  From a theoretical point of view, yes, it would be nice to have a MDN that tells the client to stop waiting for the read receipt that will never come.  However, from a practical point of view, clients must be able to deal with that situation, as it is highly likely that the read receipt will never come.

Note that in the e-mail world, only the final disposition is reported.

I am very concerned about having multiple notifications for a given message.  Consider the case of a forking proxy.  I have a pager, a SMS device, a soft client at work, a soft client at home, and a display SIP phone on my boat.  You send me a message, asking for DSN and MDN.  You will receive up to five DSNs saying "message got here" (which you knew anyway because you got 200's or 202's).  Then you will get up to five DSNs saying "message queued for delivery".  Then you will presumably get one "message read".  That is eleven status messages for a message that went on the happy path.  Imagine the explosion of messages if some of the devices are off ("message queued at the proxy" a few times) and then turn on ("message delivered to device").

Sure, it would be nice to have step-by-step notification of the message state.  However, would users really want this in the real world?

I would be happy to go either way.  I just don't like the idea of writing a bunch of specifications that never will make it past PS because no one will ever implement or use them.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple