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

From: [email-masked]
Date: Tue, 24 Feb 2004 10:26:22 +0200

I see use cases for both: report-on-failure and report-on-delivery. Some people rely on the latter to learn when a recipient actually received (not necessarily read) the IM. An natural extension to that is to learn when the IM was actually read.

BTW, I don't see IM and SMTP as a fair comparison. IM and SMS is a better comparison.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Vijay K. Gurbani
> Sent: 23.February.2004 22:26
> To: Jonathan Rosenberg; Chris Boulton
> Cc: IETF SIMPLE WG
> Subject: [Simple] Advanced IM Reqs: Delivery status reporting
> 
> 
> 
> 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
> 

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Feb 2004 16:18:28 -0600

[email-masked] wrote:

> I see use cases for both: report-on-failure and report-on-delivery. 

Problem with affirmitive delivery notification is that it
may cause notification storms when an IM is sent to a large
list.  Not all users will remember to turn delivery
notification _off_ when sending the IM to a large audience.

> Some people rely on the latter to learn when a recipient actually 
> received (not necessarily read) the IM.  

I can't argue with that, to be sure; but is that the norm?

It appears that there are two cases to consider: a) where
the IM system is tied to a presence system, and b) where
it is not.  In (a), a sender can be reasonably sure when
he sends the message that the recipient got it.  A
confirmation for each message would simply be too awkward,
given the volume of IMs that can be potentially exchanged.
(b) is more akin to email; the sender sends a message
not expecting an immediate response.  If the undelying
network fails to deliver the message, it should let the
sender know.  Otherwise, no further communications are
needed.

> An natural extension to that is to learn when the IM was actually 
> read.

I can see this as providing a utility in case (b) above.

> BTW, I don't see IM and SMTP as a fair comparison. 

For store-and-forward IM, I think SMTP is a good comparison.
For real time interactive IM, I agree, it is not.

> IM and SMS is a better comparison.

I think we can -- and must -- do better than SMS.  AFAIK,
if a SMS message is not delivered, the sender is not
notified (correct me if I am wrong).  Once a sender sends
a SMS, they generally assume that it will be delivered.
We can do one better than SMS by notifying the sender if
the IM could NOT be delivered.  If it is delivered (which
will be a majority of the case), no notification needed.

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Feb 2004 16:18:28 -0600

Thanks.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 18:40:58 -0500

It seems that there is an as yet unspecified state model for messages 
that must be understood to support delivery notifications. Some possible 
states might be SENT -> RECEIVED -> PRESENTED -> ACKNOWLEDGED. (Not all 
messages visit all states.) The delivery notification requirements seem 
equivalent to the sender asking to be notified when the message reaches 
some selected subset of these states.

I wonder if some of the confirmation load can be pushed into the 
existing protocol messages. For MESSAGE there is already a response, and 
the current MSRP proposal also has a response at the protocol level.

If this was suitably enhanced, it could tell what state of delivery the 
message had when the response was generated. If the UAS can get thru all 
the requested states without any significant delay then all the 
confirmation might be achievable in that response. If a delay is 
required, the state at the initiation of that delay could be reported. 
Then added messages will be required if notification of subsequent 
states has been requested.

	Paul

Vijay K. Gurbani wrote:
>> An natural extension to that is to learn when the IM was actually read.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 18:40:58 -0500

Paul

---

From: "Vikas Tandon" <[email-masked]>
Date: Wed, 25 Feb 2004 10:03:12 +0530

Agree with Vijay on the storm of notifications. The delivery in case of
page mode is ensured by the 200OK and in case of session is ensured by
the session being valid. Identifying the case where the user has read
the message or not is a debatable issue in case of IM as IM is typical
useful in case where you are expecting instant communication, so u can
very well assume that if the message has reached the target (ensured by
the 200OK) and there is no response from the target, then either the
target is away from the interface or is unwilling to respond at that
time.
In case of group IM, this will become more complex.

Regards,
Vikas Tandon
Arciis Software Technologies
www.arciis.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay K. Gurbani
Sent: mercredi 25 février 2004 03:48
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Simple] Advanced IM Reqs: Delivery status reporting

Problem with affirmitive delivery notification is that it
may cause notification storms when an IM is sent to a large list.  Not
all users will remember to turn delivery notification _off_ when sending
the IM to a large audience.

confirmation for each message would simply be too awkward, given the
volume of IMs that can be potentially exchanged.

> BTW, I don't see IM and SMTP as a fair comparison.

For store-and-forward IM, I think SMTP is a good comparison. For real
time interactive IM, I agree, it is not.

Thanks.

- vijay

---

From: "Vikas Tandon" <[email-masked]>
Date: Wed, 25 Feb 2004 10:03:12 +0530

Regards,
Vikas Tandon

-----Original Message-----

Thanks.

- vijay