Subject: RE: [Simple] return receipt and delivery status notification for MSRP

From: [email-masked]
Date: Thu, 1 Apr 2004 04:06:27 +0300

My question was: How useful is it to have both notification modes (positive and negative) for session IMs?  Isn't notification on failure enough?

/Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 01.April.2004 01:45
> To: Orit Levin
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Niemi Aki
> (Nokia-M/Espoo)
> Subject: Re: [Simple] return receipt and delivery status notification
> for MSRP
> 
> 
> 
> As Orit says, DSN will be very important for MSRP.
> 
> The current thinking is that MSRP relays will be session 
> stateless, and 
> that transactions are entirely hop-by-hop. The relay 
> semantics would be 
> similar to those of the SIMS draft, with MSRP syntax.
> 
> As Orit hinted, this means that a transaction response is merely an 
> indication that the transaction succeeded, not that the message has 
> reached its destination. So in non peer-to-peer sessions, DSN 
> is critical.
> 
> We do expect it to be optional, as it is much less useful in the 
> peer-to-peer case, where is just constitutes redundant messaging.
> 
> Orit Levin wrote:
> > Hisham,
> > It is VERY useful because
> > 
> > 1. MSRP hop-by-hop positive acknowledge doesn't tell you whether the
> > message was actually delivered end-to-end.
> > 2. MSRP hop-by-hop application-timer-based mechanism 
> doesn't prevent you
> > from getting negative acknowledge in a case when the message was
> > actually delivered to the destination. In other words, it 
> doesn't solve
> > a duplication problem.
> > 
> > I would like to add the requirement that the "end-to-end" 
> DSN receipt
> > needs to be requested per message (not negotiated for the 
> whole session
> > for all messages). It will allow for writing different IM behaviors
> > using the same mechanism. Such as:
> > 
> > 1. Loose IM session: all the user messages are sent without 
> receipt, but
> > the application sends a heartbeat message with requesting a 
> receipt for
> > each.
> > 2. Typical IM session: For all user messages a receipt is 
> requested but
> > the indication messages (e.g. "The user is typing") are delivered
> > without any receipt.
> > 
> > Thanks,
> > Orit.
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of
> > [email-masked]
> > Sent: Wednesday, March 31, 2004 9:26 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: [Simple] return receipt and delivery status 
> notification
> > for MSRP
> > 
> > This is a good summary, although point 4 can be debatable: 
> How useful is
> > it to request receive notification in session mode?
> > 
> > /Hisham
> > 
> > 
> >>-----Original Message-----
> >>From: ext Vijay K. Gurbani [mailto:[email-masked]]
> >>Sent: 04.March.2004 16:53
> >>To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> >>Cc: [email-masked]; [email-masked]; [email-masked]; Niemi Aki
> >>(Nokia-M/Espoo)
> >>Subject: Re: [Simple] return receipt and delivery status 
> notification 
> >>for MSRP
> >>
> >>
> >>
> >>[email-masked] wrote:
> >>
> >>
> >>>It is optional. If it is annoying to you, then you don't request a 
> >>>delivery notification. It is not every time and it is not 
> mandatory.
> >>
> >>So, just to be pedantic, please correct me if my summary below is 
> >>wrong:
> >>
> >>   1/ We are interested in DSNs at the _user_ level, not the
> >>      _protocol_ level (i.e. the transactional model at the
> >>      protocol level is sufficient for protocol state
> >>      machines to figure out if an IM was delivered to the
> >>      next hop successfully or not).
> >>   2/ We should design protocol provisions such that a positive
> >>      acknowledgement DSN model is supported (let me know
> >>      the current state of the IM: queued, delivered, read,
> >>      being responded to, ...).
> >>   3/ We should design protocol provisions such that a negative
> >>      acknowledgement DSN model is supported (send it and
> >>      forget it unless something drastic happens, then
> >>      let me know).
> >>   4/ Both 2 and 3 should apply to page mode and session
> >>      mode IMs.
> >>   5/ Both 2 and 3 should be configurable by the sending
> >>      user.
> >>
> >>Is this accurate?
> >>
> >>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
> 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 19:45:34 -0600

I don't think so. Imagine the following scenario:

A---R1---R2---B

A sends a critically important message to B, telling B to buy stock in 
messaging companies.

A sends to R1 successfully, and R1 sends to R2 successfully. But R2 
fails to send to B. So he tries to send a negative DSN to A via R1. But 
it turns out the failure killed all connectivity to and from R2, so he 
cannot send it.

The moral is, DSNs can fail just like any other kind of message. So if a 
message absolutely positively must be delivered, you need to be able to 
request positive DSN. Then A can at least notice it did not receive a 
DSN, and act accordingly.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 19:45:34 -0600

A---R1---R2---B