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

From: Rohan Mahy <[email-masked]>
Date: Wed, 3 Mar 2004 06:15:03 +0900

Hi,

I wanted to record an observation about how optional return receipt and 
delivery status notification should be for MSRP. This was inspired by 
Eric Burger's comments at the mic about how positive and negative 
acknowledgments have a different character.

	Positive Acknowledgments:
I may want to know about partial message delivery so I can interrupt 
and resume-in-place when transferring a large IM attachment (walk into 
the elevator example).

I may want to know just that a complete message was delivered

I may want to know that a complete message is queued/stored for user 
pickup

I may want to know that a complete message was displayed to the target 
end user

I may want to receive no messages at all about e2e delivery status

	Negative Acknowledgements
I may want to know that a message was not delivered due to a relay 
error and why

I may want to know that a message was not delivered because of a UA 
error (and why)

I may not care if messages don't get delivered e2e (expecting just best 
effort)

We should figure out a way to indicate which of these you want.  The 
mail folks have dealt with very, very similar problems.

Homework assignment for the working group: read and understand the 
semantics of Delivery Status Notifications (RFC 3464) and Return 
Receipts/Message Disposition Notifications (RFC 2298)

thanks,
-rohan

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 02 Mar 2004 15:55:41 -0600

Rohan Mahy wrote:

> Hi,
> 
> I wanted to record an observation about how optional return receipt 
> and delivery status notification should be for MSRP. This was 
> inspired by Eric Burger's comments at the mic about how positive 
> and negative acknowledgments have a different character.

Rohan:

I had started a thread related to Delivery Status reporting
last week (in response to Jonathan's I-D on Advanced
IM requirements).  The thread can be followed from the
following URI:

http://www1.ietf.org/mail-archive/working-groups/simple/current/msg02150.html

The summary of the thread was that it would be good to have
both positive and negative acknowledgements.  Buried in the
thread is a following observation which is of interest,
especially given the email tie-in you mention:

    It appears that there are two cases to consider: a) where
    the IM system is tied to a presence system, and b) where
    it is not.  In (a), a sender can be reasonably sure when
    he sends the message that the recipient got it.  A
    confirmation for each message would simply be too awkward,
    given the volume of IMs that can be potentially exchanged.
    (b) is more akin to email; the sender sends a message
    not expecting an immediate response.  If the undelying
    network fails to deliver the message, it should let the
    sender know.  Otherwise, no further communications are
    needed.

In this view, positive acknowledgements have limited use
if the IM user is tied to a presence system, but have
tremendous uses if the IM interface is not tied to a presence
system.  In short, I think negative acknowledgements should
be the norm (a la email), but positive acknowledgements
should be used if the sender of IM does not know what the
current presence and availability status of the receiver is.

> I may want to know about partial message delivery so I can interrupt and 
> resume-in-place when transferring a large IM attachment (walk into the 
> elevator example).
> 
> I may want to know that a complete message is queued/stored for user pickup
> 
> I may want to know that a message was not delivered due to a relay error 
> and why
> 

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 02 Mar 2004 15:55:41 -0600

Rohan:

Thanks,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Mar 2004 18:46:17 -0500

Vijay K. Gurbani wrote:

>> and delivery status notification should be for MSRP. This was inspired 
>> by Eric Burger's comments at the mic about how positive and negative 

I can be available but the message can fail to be delivered due to 
error. Lets not confuse presence availability with guaranteed message 
delivery.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Mar 2004 18:46:17 -0500

-Jonathan R.

---

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

I agree that availability of presence may have some impact on 
need/desire for delivery confirmations. Sending the message via session 
mode rather than page mode does too. But I don't agree these 
circumstances are definitive for whether receipts of any kind are 
desired. I think the most you can really say is that the sender can 
choose which kind (if any) is desired.

	Paul

Vijay K. Gurbani wrote:
>> I may not care if messages don't get delivered e2e (expecting just 
>> best effort)
>>

---

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

Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:18:44 +0900

Agreed. Presence information does not guarantee message delivery. As 
Adam mentioned in his service-feature draft, presence is really just a 
hint. It does not make sense to assume delivery success based on 
presence information.

Paul Kyzivat wrote:
>>> inspired by Eric Burger's comments at the mic about how positive and 
>>> negative acknowledgments have a different character.
>>
>>
>>
>> Rohan:
>>
>>> and resume-in-place when transferring a large IM attachment (walk 
>>> into the elevator example).
>>>
>>> I may want to know that a complete message was displayed to the 
>>> target end user
>>>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:18:44 +0900

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 03 Mar 2004 04:27:51 +0200

Hi Rohan,

I'm a little confused whether we're talking about MSRP or page-mode, or
both here.

I definitely agree that there is a need to get both bounces back to the
client (e.g. when the MESSAGE receives a 202 and is stored but later
delivery fails, or when using a message list server, where some
recipients return a non 2xx response); and also read-reports for when an
IM was actually rendered to a user and thus read.

I think these features are tremendously useful for page mode, but I'm
not sure they're all that useful for MSRP, which is already an
interactive form of communication. I.e., if I don't get my message
across, I can send it again - this time in block letters...

Cheers,
Aki

ext Rohan Mahy wrote:
> Positive Acknowledgments: I may want to know about partial message
> delivery so I can interrupt and resume-in-place when transferring a
> large IM attachment (walk into the elevator example).
> 
> Negative Acknowledgements I may want to know that a message was not
> delivered due to a relay error and why
> 
> thanks, -rohan
> _______________________________________________ Simple mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/simple

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Wed, 03 Mar 2004 04:27:51 +0200

Hi Rohan,

Cheers,
Aki

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 3 Mar 2004 16:00:50 +0900

Hi,

I was trying to gather reqs for MSRP.  I don't think it is appropriate 
to offer a full range of services for page-mode.

Because relays can chunk and acknowledge SEND requests hop by hop, it 
is useful to get positive acknowledgments that you wouldn't have 
otherwise.  For the human typing text to a human I agree you probably 
don't need e2e message delivery notification, but part of my point was 
that there are several different applications.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 3 Mar 2004 16:00:50 +0900

Hi,

thanks,
-rohan

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Mar 2004 16:31:28 -0600

[Sorry for multiple postings -- I have'nt seen it reflected on
  the list.  Maybe the Bagel virus is to blame]

[email-masked] wrote:

> Yes, in chunking, I think it is useful to get
> delivery reports of chunks. Not for every chunk, but
> for x number of them.

Receipt of X chunks is a protocol-level status notification.
I am confused -- what kind of DSNs are we talking about?
Protocol level or user level?

Opening a dialog box to the user and telling him or her
that "The 9th chunk has been successfully delivered" will
probably not impart too much information to the user.  But
opening a dialog box that says "Message could not be
delivered -- receiver exceeds disk quota to store the message"
is more meaningful to the sender.

User level DSNs may be influenced by presence (I agree with
others who point out that presence is not a pre-requisite
for guaranteed delivery) and by the type of IM session:
page or session mode.

For page mode, Hisham wants to be notified not only
when the IM was delivered but also when it was read.
On the other hand, I want to be only notified if the
message could not be delivered (i.e. I would consider
an intermediary accepting the IM on behalf of an offline
receiver as successful delivery but would like to know if
the receiver has run out of disk space or no longer has
a login in that domain).

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Mar 2004 16:31:28 -0600

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Mar 2004 10:36:43 -0600

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Mar 2004 10:36:43 -0600

- vijay