Subject: [Simple] Advanced IM Reqs: Delivery status reporting

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Feb 2004 14:25:56 -0600

Jonathan/Chris:

Re: requirements for DSN (delivery status notifications) in IM
     in <draft-rosenberg-simple-messaging-requirements-01>

First off, to provide some context for these requirements, I
suggest we tie the requirements closely to rfc3428 which
states that:

    If confirmation of delivery is required for a message
    that has been responded to with a 202 Accepted, that
    confirmation  must be delivered via some other mechanism,
    which is beyond the scope of this specification.

Second, I believe that DSN is such an integral part of IMs
that it should be the default mode of operations.  That is, a
successful delivery should not elicit a notification, an
unsucessful one must.  This will help in REQ-DELNOT-11
since according to REQ-DELNOT-12, the resulting storm of
successful DSNs will create quite a vast overhead (exactly
the thing REQ-DELNO-11 is trying to avoid).

I do not know if this idea of notify-only-on-failure has
been explored to any length in conjunction with IMs.  Chris
Boulton's <draft-boulton-sipping-message-recepit-00> draft
can actually be leveraged nicely here -- instead of it
reporting successful deliveries, it will report UNsuccessful
attempts.

Since rfc3428 is still a proposed standard, is it worthwhile
to think about putting a notify-on-failure feature into
it as it progresses to draft standard?  Or am I indulging
in what Greenspan would called "cheerful and optimistic
naiviete" :-)

SMTP uses notify-on-failure as the default notification model; i.e.
it will inform a sender if it could not deliver the message to a
recipient (no such user, over disk quota, etc).  I find this
immensely useful, more in the light that SMTP also has a DSN
extension (rfc3461) which, in my experience, has not been
uniformly implemented.  I have had spotty luck in getting DSN
even when I actively checked the button for a "return reciept".
If we leave it as an extension to SIP IM, we may suffer
the same fate.  I depend on SMTP failure notification much
more than I do on SMTP DSN extension to determine if a user
got an email I send them.

Are there technical reasons on why we cannot make
notify-on-failure the default mode in IM?

Other comments:

REQ-DELNOT-3 is probably driven by a IM being queued at
an intermediary (202 Accepted) for later delivery.  If so,
could we state that somewhere -- it took me a while to
figure out why this requirement is there.  After all, if a
sender sends an IM out, he or she would like to be notified
immiedately.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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