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

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 13:54:32 -0600

Eric Burger wrote:
> nononononononono.
> 
> We are confusing two, different concepts here.  A DSN lets the sender know that a relay attempt failed.  IMHO, a positive DSN has not practical value (other than generating information that "might be useful", but of no use).  ["Useful" information is how long it takes a message to traverse the relays.  What user cares?]
> 

I had not confused the concepts. I was arguing that it was useful to get 
a report saying that an IM was successfully delivered to the endpoint. 
That seems to me to fit the definition of DSN more than MDN. But I might 
be able to be convived otherwise (see below.)

> A MDN lets the sender know that the recipient received the message.
> 
> If you are a *user*, and you want to *know* if someone received a message, you are going to request a MDN.

If I understand correctly, you are arguing that the useful information 
is not whether it was delivered to the endpoint, but whether the user 
actually saw it. (Or consumer consumed it, to be more generic.) Is that 
the point?

If so, I do not have strong feelings one way or another. I am willing to 
accept that, for critical delivery, the thing I care about is that the 
message was consumed, rather than merely delivered.

But I continue to hold the opinion, that you need some form of positive 
acknowledgement for sufficiently important messages, whether it be 
positive DSN or MDN. Negative DSN by themselves are insufficent, because 
they can also fail. Positive acknowledgement gives us a fail-safe mode.

> 
> 
> Let's look at two cases from the example again:
> 
> A --> R1 --> R2 --> B
> 
> First case:
> A sends to R1
> R1 tries to send to R2, but nobody is home.
> R1 sends Failure DSN to A
> A knows message was not delivered.  Why?  Because A receives the DSN.
> 
> 
> Second case:
> A sends to R1
> R1 sends to R2 (successfully - no DSN)
> R2 disappears (no DSN)
> A *knows* B did not get the message.
> How does A know this?  Because A requested a MDN, and it never got it.

To be pedantic, you do not know it was _not_ delivered. You just have 
reason to believe it might not have been delivered. Close, but not the 
same. B may have ignored the MDN request, or the MDN itself may have 
failed in transit.

> 
> One might say that A cannot tell the difference between a delivery failure and the user ignoring the message.  One might say that one would be correct in that assertion, and that is by design.
> 

[...]

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 02 Apr 2004 13:54:32 -0600

[...]

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 2 Apr 2004 12:47:44 -0500

nononononononono.

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

First case:
A sends to R1

Second case:
A sends to R1

> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]]
> Sent: Thursday, April 01, 2004 4:24 AM
> To: Ben Campbell; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] return receipt and delivery status notification
> for MSRP
> 
> 
> I agree with Ben.  If an entity requests delivery confirmation, it
> cannot rely on the absence of a failure DSN to convey that the message
> was delivered successfully.  So I feel that there is scope for both
> failure/success DSN's and a requirement for appropriate text 
> describing
> procedures for the scenario where a positive DSN is requested BUT none
> received.
> 
> Out of interest - what are the current thoughts on exactly 
> how a client
> will request a DSN conformation?
> 
> 
> Chris.
>  
> 
> >-----Original Message-----
> >From: Ben Campbell [mailto:[email-masked]]
> >Sent: 01 April 2004 02:46
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked];
> >[email-masked]; [email-masked]
> >Subject: Re: [Simple] return receipt and delivery status notification
> for
> >MSRP
> >
> >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.
> >
> >
> >[email-masked] wrote:
> >> 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
> >>>>>
> >>>>
> >>>>
> This message has been scanned for viruses by MailControl - 
www.mailcontrol.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Apr 2004 17:37:50 -0500

Eric,

I can't speak for the others, but I have been lumping the notion of MDN 
into DSN - perphaps distinguished by options or something. Maybe it is 
useful to distinguish the two types, maybe not.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Apr 2004 17:37:50 -0500

Eric,

	Paul