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

From: [email-masked]
Date: Wed, 3 Mar 2004 09:46:27 +0200

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

I disagree about your opinion on page-mode. Delivery reports are most appropriate in page-mode. I like to know when I send an IM that it was received. It is also an indication to me on WHEN it was received (in a store and forward mode). For Aki, he just wants to be notified when an error occurs.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Rohan Mahy
> Sent: 03.March.2004 09:01
> To: Niemi Aki (Nokia-M/Espoo)
> Cc: [email-masked]; Rohan Mahy
> Subject: Re: [Simple] return receipt and delivery status notification
> for MSRP
> 
> 
> 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
> 
> 
> On Mar 3, 2004, at 11:27 AM, Niemi Aki (Nokia-M/Espoo) wrote:
> 
> > 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:
> >> 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
> 
> 
> _______________________________________________
> 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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Mar 2004 08:55:19 -0600

[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
-- 
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: Wed, 03 Mar 2004 08:55:19 -0600

- vijay