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

From: "Chris Boulton" <[email-masked]>
Date: Thu, 1 Apr 2004 10:23:42 +0100

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
>>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

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

---

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

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?]

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.

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.

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.

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Thursday, April 01, 2004 4:24 AM
> To: Ben Campbell; [email-masked]
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] return receipt and delivery status notification
> for MSRP
> 
>

---

From: [email-masked]
Date: Mon, 5 Apr 2004 10:09:05 +0530

Eric,

In general:

MDN are like: READ Receipt with additional parameters  like :on
Successful delivery the recipient's refusal to provide MDNs
Or deletion (without display) of the message or display of the message
contents

DSN  are :delivery receipts that notify that the message has arrived in
the recipient's inbox on the server.

So both give the response success or failure of the message.
----

I think we should give response for both (SUCCESS and FAILURE) in MSRP.

Please correct my understanding.

Thanking you,

Regards,
Sreeram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Saturday, April 03, 2004 4:08 AM
To: Eric Burger
Cc: Chris Boulton; Ben Campbell; [email-masked];
[email-masked]
Subject: Re: [Simple] return receipt and delivery status notification
for MSRP

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

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?]
> 
> 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.
> 
> 
> 
> 

>>failure/success DSN's and a requirement for appropriate text 
>>describing procedures for the scenario where a positive DSN is 
>>requested BUT none received.
>>
>>>A sends a critically important message to B, telling B to
>>
>>buy stock in
>>
>>>messaging companies.
>>>
>>>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
>>

>>>(positive and negative) for session IMs?  Isn't notification
>>
>>on failure
>>
>>>enough?
>>>
>>>>/Hisham
>>>>
>>>>
>>>>
>>>>>The current thinking is that MSRP relays will be session stateless,

>>>>>and that transactions are entirely hop-by-hop. The relay
>>>>>semantics would be

>>>>>reached its destination. So in non peer-to-peer sessions, DSN is 
>>>>>critical.
>>>>>
>>>>>>1. MSRP hop-by-hop positive acknowledge doesn't tell you
>>>>>
>>whether the
>>
>>>>>>for all messages). It will allow for writing different IM
>>>>>
>>behaviors
>>
>>>>>>>>It is optional. If it is annoying to you, then you
>>>>>>>
>>don't request a
>>
>>>>>>[email-masked] https://www1.ietf.org/mailman/listinfo/simple
>>>>>>
>>>>>>[email-masked] https://www1.ietf.org/mailman/listinfo/simple
>>>>>
>>>>>
>>>
>>This message has been scanned for viruses by MailControl - 
> 
> www.mailcontrol.com
>

---

From: [email-masked]
Date: Mon, 5 Apr 2004 10:09:05 +0530

Eric,

In general:

Thanking you,

Regards,
Sreeram

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

Eric,

	Paul

---

From: [email-masked]
Date: Mon, 5 Apr 2004 10:45:54 +0530

Added to that,
I understand that MSRP is hop-to-hop so the DSN are not in this case
upto the end receipt!!

So,my comments:
1.we should give response for both success and failure responses (DSN)
2.we should define MDN and DSN if needed as per MSRP 

-Sreeram

-----Original Message-----
From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) 
Sent: Monday, April 05, 2004 10:09 AM
To: 'Paul Kyzivat'; Eric Burger
Cc: Chris Boulton; Ben Campbell; [email-masked];
[email-masked]

Eric,

In general:

MDN are like: READ Receipt with additional parameters  like :on
Successful delivery the recipient's refusal to provide MDNs Or deletion
(without display) of the message or display of the message contents

Thanking you,

Regards,
Sreeram

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

Eric,

	Paul

>>Out of interest - what are the current thoughts on exactly how a 
>>client will request a DSN conformation?
>>
>>
>>Chris.
>> 
>>
>>

---

From: [email-masked]
Date: Mon, 5 Apr 2004 10:45:54 +0530

Added to that,

So,my comments:

-Sreeram

-----Original Message-----
From: Sreeram Kanumuri (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) 
Sent: Monday, April 05, 2004 10:09 AM
To: 'Paul Kyzivat'; Eric Burger
Cc: Chris Boulton; Ben Campbell; [email-masked];
[email-masked]

Eric,

In general:

Thanking you,

Regards,
Sreeram

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

Eric,

	Paul

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 5 Apr 2004 12:24:31 +0100

>From: Eric Burger [mailto:[email-masked]]
>Sent: 02 April 2004 18:48
>To: Chris Boulton; Ben Campbell; [email-masked]
>Cc: [email-masked]
for
>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?]

[Chris Boulton] You care if you are sending an important message using a
hop-by-hop protocol ;-)  Receiving a positive DSN from the final
destination of the request ensures delivery - Not receiving a negative
DNS does not provide me with guarantee of delivery.

Chris.

>If you are a *user*, and you want to *know* if someone received a
message,
>you are going to request a MDN.
>
>
failure
>and the user ignoring the message.  One might say that one would be
correct
>in that assertion, and that is by design.
>
>
>
>> describing
notification
>> >>>>>Vijay K. Gurbani
vkg@{lucent.com,research.bell-labs.com,acm.org}

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 5 Apr 2004 12:24:31 +0100

for
know
value
use).

Chris.

message,
failure
correct
notification

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 5 Apr 2004 09:37:36 -0400

DSN's get issued by MSRP proxies, just like DSN's get generated by MTA's in SMTP.

MDN's get issued by MSRP endpoints (a.k.a. SIP UA's), just like MDN's get generated by MUA's in SMTP.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 05, 2004 1:16 AM
> To: [email-masked]; [email-masked]; Eric Burger
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Or deletion
> > message, you are going to request a MDN.
> >
> 
> >
> 
> stateless,
> Confidentiality Notice
> The information contained in this electronic message and any 
> attachments to this message are intended
> for the exclusive use of the addressee(s) and may contain 
> confidential or privileged information. If
> you are not the intended recipient, please notify the sender 
> at Wipro or [email-masked] immediately
> and destroy all copies of this message and any attachments.
> 
>

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 5 Apr 2004 09:37:36 -0400

Ben gets it in one...

As the sender of the message, there is no difference between any of the following scenarios:

1. The message is delivered, but the user does not read it.
2. The message is delivered, but the user ignores it.
3. The message is delivered, the user reads it, but the user blocks receipt generation.
4. The message is not delivered.

All of those scenarios, including #3, fall into the "Recipient did not get the message".

The security implications of #3 are more then enough to suggest that generating a Positive DSN on message receipt at a UAS is a bad idea.

On a separate thought, is the plan to have SIMPLE replace SMTP for messaging?  I thought SIMPLE was for real-time communications, while ESMTP, with its myriad of non-real-time certification facilities, would be the place for things like "Registered Delivery With Return Receipt Delivery With Signatures from Every Person That Handled the Message".

> Sent: Friday, April 02, 2004 2:55 PM
> To: Eric Burger
> Cc: Chris Boulton; [email-masked]; [email-masked]
> > 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.)
> 
> > 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.
> 
> 
> > 
> > 
> 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.
> > 
> 
> [...]
>

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 5 Apr 2004 09:37:36 -0400

> the sender

---

From: [email-masked]
Date: Tue, 6 Apr 2004 10:02:27 +0300

> From: ext Eric Burger [mailto:[email-masked]]
> Sent: 05.April.2004 16:38
> To: Ben Campbell
> Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
> [email-masked]

"Message is delivered" is not the same as "message is not delivered". In cases 1-3, the sender knows that it was a receiver action that stopped the MDN since he will get a DSN saying that message is delivered.

/Hisham

> 
> The security implications of #3 are more then enough to 
> suggest that generating a Positive DSN on message receipt at 
> a UAS is a bad idea.
> 
> On a separate thought, is the plan to have SIMPLE replace 
> SMTP for messaging?  I thought SIMPLE was for real-time 
> communications, while ESMTP, with its myriad of non-real-time 
> certification facilities, would be the place for things like 
> "Registered Delivery With Return Receipt Delivery With 
> Signatures from Every Person That Handled the Message".
> 
>

---

From: [email-masked]
Date: Tue, 6 Apr 2004 10:02:27 +0300

/Hisham

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 6 Apr 2004 14:29:39 -0400

And if the receiver is sensible, she will set her UAS options to never offer positive DSN, making it useless.

I could see putting it in the protocol if one was looking to deploy such a system where there were legal implications of a message being delivered (financial services?).  However, wouldn't e-mail be better for that?

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 06, 2004 3:02 AM
> To: Eric Burger; [email-masked]
> Cc: [email-masked]; [email-masked]
> "Message is delivered" is not the same as "message is not 
> delivered". In cases 1-3, the sender knows that it was a 
> receiver action that stopped the MDN since he will get a DSN 
> saying that message is delivered.
> 
> /Hisham
> 
> > 
[snip]