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

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 23 Feb 2004 14:52:58 -0800

I definitely think that ["send-and-forget" + "notify on failure(s)"] is
the most useful mode for scalable IM protocol and needs to exist in any
basic MSRP.

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay K. Gurbani
Sent: Monday, February 23, 2004 12:26 PM
To: Jonathan Rosenberg; Chris Boulton
Cc: IETF SIMPLE WG
Subject: [Simple] Advanced IM Reqs: Delivery status reporting

Jonathan/Chris:

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

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

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 23 Feb 2004 14:52:58 -0800

Orit.

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

Jonathan/Chris:

Other comments:

Thanks,

- vijay

---

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Vijay K. Gurbani
> Sent: 23.February.2004 22:26

---

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

Note that we are talking about a delayed delivery on a message. If a message delivery was immediately unsuccessful, you would send a 4xx back to the SIP MESSAGE or MSRP SEND.

/Hisham

> ext Orit Levin
> Sent: 24.February.2004 00:53
> To: IETF SIMPLE WG
> Subject: RE: [Simple] Advanced IM Reqs: Delivery status reporting
> 
> 
> 
>  
> suggest we

---

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

/Hisham

---

From: [email-masked]
Date: Wed, 25 Feb 2004 08:53:20 +0200

> From: ext Vijay K. Gurbani [mailto:[email-masked]]
> Sent: 25.February.2004 00:18
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] Advanced IM Reqs: Delivery status reporting
> 
> 
> 
> [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.

SMS has delivery reports. If we want to do better, then we need allow both delivery report and failure report.

To answer your concern about the notification storm, there is some work going on right now in sipping to handle this situation. See the links below.

http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transac-package-00.txt

/Hisham

> Thanks.

---

From: [email-masked]
Date: Wed, 25 Feb 2004 08:53:20 +0200

/Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 25 Feb 2004 09:27:07 -0000

Comments in-line - <<CJB>>.

	-----Original Message----- 
	From: Vikas Tandon [mailto:[email-masked]] 
	Sent: Wed 25/02/2004 04:33 
	To: 'Vijay K. Gurbani'; [email-masked] 
	Cc: [email-masked]; Chris Boulton; [email-masked] 
	Subject: RE: [Simple] Advanced IM Reqs: Delivery status reporting

	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.

	<<CJB>> The 200 OK indicates the completion of a transaction.  I don't see how this indicates the delviery

	of the MESSAGE to the required destination (e.g. your handset is turned off - the transaction would complete but the message would be delivered at a later date).

	 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,

	<<CJB>> This draft is initially refering to pager-mode, one off massaging.  I wouldn't expect an

	instance response to an SMS-style message. 

	 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.

	<<CJB>> I disagree - based on previous comments.

	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

	

This message has been scanned for viruses by MailControl - www.mailcontrol.com
�jezf��)��+-J)��螵�+�m����5��_��?�������+-�w��Ȧ�W