Subject: RE: [Simple] RE: Advanced IM requirements

From: "Eric Burger" <[email-masked]>
Date: Mon, 1 Mar 2004 17:10:16 -0500

The first example is where the message sender is in a session and wants a notification on a particular message.  In that case, one could argue that the notification is still a one-shot message, and does not need a session.

I could see that someone could request confirmation on every message they send.  In that case, an optimization would be to have the notifications streamed.  That said, I think that use case really would drive a different protocol (Reliable IM?).

The second example is where the message sender sends a message to an exploder or conference bridge.  The first thing we should consider is whether the notification comes from the exploder/bridge or from the endpoints themselves.  In the SIP world, it does make a difference if we are talking exploder vs. bridge.  In the exploder case, the notifications come from the endpoints themselves.  Stream mode for the responses does not necessarily help.

In the bridge case, the endpoint only has a dialog with the bridge.  Thus, the bridge is where the notification has to come from.  The bridge could act as a state agent, optimizing network usage either by aggregating responses or opening a session for notifications.

Am I off-base in thinking the transport mode (stream v. one-shot) is independent of the notification?

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 1:44 AM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: [Simple] RE: Advanced IM requirements
> 
> 
> 
> 
> Eric Burger wrote:
> > I agree.  Again, this highlights why IMDN is at the CPIM, 
> and not SIP, level.
> > 
> > Further, what is the use case for MDN in session mode?  
> Would anyone EVER use it?  I doubt it: if you are in a 
> session, presumably you are interactive, which means you have 
> OOB methods for knowing the message wasn't read (e.g., no 
> response from the other person).
> 
> I agree it doesn't seem like something that normally would be 
> used. But 
> there may be some cases. I may want explicit confirmation that a 
> particular message has not only been delivered, but read. (This might 
> require the UAS to demand some explicit confirmation from the 
> end user 
> before sending the confirmation.)
> 
> Another case is with an IM conference. If I send a message to 
> the mixer, 
> requesting confirmation, ideally that would be an end-to-all-ends 
> confirmation. The mixer would have to request and receive 
> confirmation 
> from all recipients before confirming to sender.
> 
> > Given that assertion, can we say IMDN's are page mode messages.
> 
> Based on above, I say NO.
> 
> 	Paul
> 
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:21:20 -0500

> I could see that someone could request confirmation on every message they send.  In that case, an optimization would be to have the notifications streamed.  That said, I think that use case really…

Yes, I agree.

> Am I off-base in thinking the transport mode (stream v. one-shot) is independent of the notification?

The reason I posted this message was that in a prior message you seemed 
to be suggesting that delivery notification might not be required for 
session mode messages.

I too think that the mode (page/session) used for delivery notifications 
is independent of the mode used for the message being confirmed.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:21:20 -0500

Yes, I agree.

	Paul