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

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

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 16:44:36 -0600

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 16:44:36 -0600