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: "vikas" <[email-masked]>
Date: Thu, 04 Mar 2004 05:30:49 +0000

Hi,

Adding to what Vijay just mentioned, it would be annoying for the user to get a notification everytime that the message has been read by the target. 

Typically the number of messages exchanged in IM will be greater than that in email (if you would like to compare for read notification purpose). 

To me - "no news is good news" sounds okay for delivery notifications.

Regards,
Vikas Tandon
Arciis Software Technologies
www.arciis.com

   -------Original Message-------
   > From: Vijay K. Gurbani <[email-masked]>
   > Subject: Re: [Simple] return receipt and delivery status notification for MSRP
   > Sent: 03 Mar 2004 16:36:43
   >
   >  [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
   >  
   >  
   -------Original Message-------

---

From: [email-masked]
Date: Thu, 4 Mar 2004 12:24:15 +0200

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.
 
/Hisham

-----Original Message-----
From: ext vikas [mailto:[email-masked]]
Sent: 04.March.2004 07:31
To: Vijay K. Gurbani; ; Rohan Mahy; Niemi Aki (Nokia-M/Espoo); Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
Subject: Re: [Simple] return receipt and delivery status notification for MSRP

Hi,

Regards,
Vikas Tandon

---

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

> 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
> 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 that a complete message was displayed to the
> >> target end user
> >> Negative Acknowledgements I may want to know that a message was not
> >> delivered due to a relay error and why
> >> I may not care if messages don't get delivered e2e (expecting just
> >> best effort)
> >> thanks, -rohan
> >> _______________________________________________ Simple 
> mailing list 
> >> [email-masked] https://www1.ietf.org/mailman/listinfo/simple
> 
>

---

From: [email-masked]
Date: Wed, 31 Mar 2004 20:26:20 +0300

This is a good summary, although point 4 can be debatable: How useful is it to request receive notification in session mode?

/Hisham

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

---

From: [email-masked]
Date: Wed, 31 Mar 2004 20:26:20 +0300

/Hisham

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 31 Mar 2004 13:11:14 -0800

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

> > 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:
> 
> Wireless Networks Group/Internet Software and Services Lucent 
> Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440

---

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

> 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)
> 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,
> >>Subject: Re: [Simple] return receipt and delivery status 
> notification 
> >>for MSRP
> >>
> >>
> >>

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 31 Mar 2004 17:22:26 -0800

OL: I see the opposite, actually. The applications should not care of
the underlying topology (do we deploy relays or not) and must not change
their interface or behavior based on that. In the "no relay" single MSRP
hop deployment, the hop-by-hop mechanism is redundant because (hopefully
well-configured) TCP does the job.

Orit.
-----------------------
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.

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 31 Mar 2004 17:22:26 -0800

Orit.
-----------------------