Subject: Re: [Simple] MSRP: DSN lifetime open issue

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2004 08:30:00 -1000

Every real IM system I use, including SMS, supports stored messages. Seems
like a desirable property of an "Instant" messaging system. Not sure what
that means for DSN.

On 4/16/04 12:22 AM, "[email-masked]"
<[email-masked]> wrote:

> This is a session mode instant messaging, therefore I would think that
> participants would not care about any DSNs after the session has been torn
> down. If they want the DSN, then they need to wait before tearing down the
> session.
> 
> In page mode, you would need to allow the DSN to come days later. But that is
> not the issue here.
> 
> I guess I'm suggesting that all outstanding DSNs are discarded. I don't think
> that the penalty that the relay has to try to send the DSN anyway is such a
> huge problem. If it is, then we probably need to send a MSRP level BYE request
> that traverses relays.
> 
> /Hisham
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>> ext Ben Campbell
>> Sent: 15.April.2004 18:31
>> To: Simple WG
>> Subject: [Simple] MSRP: DSN lifetime open issue
>> 
>> 
>> One open issue concerning MSRP usage of DSN that I would like
>> to close 
>> on is, what happens to DSNs after a session is torn down?
>> 
>> Example:
>> 
>> A          R           B
>> SEND------->
>> <---------OK
>>             SEND----X
>> <---session teardown--->
>> <-----REPORT
>> 
>> 
>> In this example, A sends a message to B via relay R. The
>> A-->R hop works 
>> fine. The R->B hop failes, due to a tcp error. For the sake
>> of argument, 
>> consider this to be a worst case TCP error where the TCP stack has to
>> work through the entire retransmission sequence before it
>> gives up, that 
>> is, a non-trivial amount of time passes.
>> 
>> A and B tear down the session. But since R is not session
>> stateful, it 
>> does not know about this.
>> 
>> So, the question becomes, what happens to outstanding DSN after a
>> session is closed? Do they just get dropped? (This is not as
>> simple as 
>> it sounds, since if a relay is not aware of the session
>> closure, it will
>> still try to send the DSN, wasting resources.)
>> 
>> Or, do we want to be able to deliver DSN outside of the scope of the
>> session in which it was generated?
>> 
>> I have had several offline discussions with people, and have gotten
>> opinions that range from allowing DSN to be sent days later,
>> to assuming 
>> that all outstanding DSN just get discarded.
>> 
>> Thoughts?
>> 
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>> 
> 
> _______________________________________________
> 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: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2004 08:30:00 -1000

---

From: Ben Campbell <[email-masked]>
Date: Mon, 03 May 2004 11:58:01 -0500

The model is a little different here, though. None of those systems that 
  I am aware of have anything at all like the concept of doing an SDP 
exchange between endpoints to initiate a message session.

So, I don't expect that mid-stream messages will suddenly start going to 
some long-lived store and forward service (I define long-lived here to 
mean longer than something a normal MSRP relay does as a normal part of 
relaying messages). Rather, I expect that if the destination user was 
not available, the SIP fabric may proxy or redirect you to a message 
store of some kind. This is exactly analogous to a voice call being 
directed to a voice mail service.

When this happens, the message store _is_ the destination of the message 
session. A DSN tells you a message has reached the message store. I 
think the mechanism of delivery between that store and the final 
recipient is out of scope. A mechanism of acknowledging final delivery 
would be nice, but I don't think it is the same as an in-session DSN.

I know I am in the minority on the following point, but I think we have 
a perfectly good system for doing this now. If the SIP fabric cannot 
reach the final destination, it redirects you to a "mailto" URI. From 
that point on, delivery notification follows email methods, not message 
session methods.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 03 May 2004 11:58:01 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 May 2004 08:45:34 -0400

> that point on, delivery notification follows email methods, not message 

I think that is a fine idea!

It would be a good thing if there was more uniformity and continuity 
between all these communications systems - email, IM, and voice.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 May 2004 08:45:34 -0400

Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 May 2004 13:29:03 -0500

> like a desirable property of an "Instant" messaging system. Not sure what

I would LOVE to be able to turn off stored messages on Yahoo IM. The 
fact that it SOMETIMES works encourages people to use IM as an email 
replacement, which makes for some really gnarly communication failures. 
What part of "instant" do we not understand?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 May 2004 13:29:03 -0500

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 04 May 2004 20:03:56 -0700

Hmm, looks like what you don't like about yahoo stored messages is that they
don't work reliably.

Stored messaging is a very clear market requirement for IM systems - I don't
know if that means the SIMPLE group should have anything to do with it or
not but it's interesting to note the tone that the SIMPLE WG groups takes to
this and contrast that with jabber folks that clearly had this done by
JEP-0023 which was voted active on Active on 2002-07-15.

Given our current rate of progress, I'm not really in favor of doing
anything but the bare minimum.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 04 May 2004 20:03:56 -0700