Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 1 Mar 2007 16:02:25 -0600

Since I've been very slow in answering this, here's an attempted
overview of the discussion to date, followed by a question about where
this leads:

First of all, I think the telegraphic summary (was it provided by
Miguel?) is pretty good:
> - An MSRP session is intercepted by a store-and-forward server. The 
> sender would like to be informed when the final recipient receives or 
> reads the message(s).

I guess it's an open question whether the group is interested in
disposition notification functionality for sessions as a whole. (That
wasn't what we were thinking about when we put together the draft.)

The main *concern* that came up was: in an interactive session with
numerous messages, you wouldn't want to have sender(s) requesting
disposition notification on a per-message basis. 

That concern led to the idea of: you'd need a way to distinguish between
large message mode and a "true" session based experience. Jerry Shih's
clarification at the time- regarding OMA's large message mode
definition- was that the large message originator's client would specify
send-only in the SDP session negotiation. So, if the intended recipient
*did* happen to be online, said recipient would not be able to
misconstrue and jump into a back-and-forth exchange where it too was
asking for disposition notification. So it looks like we've got it
boiled down to a question of the session initiator's behavior.

My question now: suppose we were to say the originator MUST NOT
incorporate DN requests in multiple MSRP messages in the same session,
and moreover MUST specify send-only if it wants to request DN. (Even if
a single message were chunked into multiple MSRP SENDs, I'm assuming you
wouldn't want to have DN headers in each chunk- I'm thinking of the DN
business as residing at a higher layer.)

Would this sort of requirements be adequate? Or are we talking instead
about a feature-tag or some other explicit identifier that we are in
large message mode? 

Best,
Matt Stafford

-----Original Message-----
From: Salvatore Loreto (JO/LMF) [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 7:40 AM
To: Miguel Garcia
Cc: Stafford, Matthew; [email-masked]'
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Miguel,

see the discussion on line

br
/sal

> > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote:
> >> Hi:
> >>
> >> So, a summary of draft-stafford-simple-dmdn is  that there is a use
case 
> >> that is not covered by the current IMDN, which is:
> >>
> >> - An MSRP session is intercepted by a store-and-forward server. The

> >> sender would like to be informed when the final recipient receives
or 
> >> reads the message(s).
> >>
> >> One first question about the use case. It appears form the text in
the 
> >> draft that the use case applies only to large messages. However, I
can 
> >> envision store-and-forward servers that store a complete MSRP
session 
> >> (not only ONE large message).
> > 
> > you are right, if you have a store-and-forward in the path this is a
> > possible scenario, even if I can not imagine at present a specific
use
> > case. (e.g. Why someone would establish a MSRP session with an
off-line
> > user and start to chat with him?)
> 
> 
> Well, look at commercial systems. They do it. I can do it. I actually
do 
> it... I establish a session with some offline friend to send a few 
> messages, or pending items, such as my latest pictures. This is a real

> use case.

Yes I am aware that some IM programs behave in this way.
What I don't see is the necessity to have or provide a delivery
notification in this scenario, and in fact they don't do.
But I understand and fully agree with your concern about adding some
header for Deliver Notification in the CPIM headers of each MSRP SEND
request.

> 
> 
> >> I think it is important to consider these collections of MSRP
messages, 
> >> because, imagine we add something to the CPIM headers of each MSRP
SEND 
> >> requesting delivery disposition notification, then the sender will 
> >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND 
> >> request. I guess this is not reasonable.
> > 
> > I agree. 
> > A solution could be that the store-and-forward server collect all
the
> > message in one single big message, but in this case it shouldn't be
any
> > more a simple store-and-forward.
> 
> Certainly that is one possibility. Another one is to promote the IMDN 
> request to the INVITE, and provide a "session-level" IMDN.

yes, promoting the IMDN request to the INVITE could work in both the
scenario: the only one large message and several short/normal messages.
It can say to the final recipient to send an IMDN to the original sender
when as soon as he has received the whole large message or all the short
messages. For example as soon the store and forward server close the
MSRP session.
But promoting the IMDN request to the INVITE levels means we have also
put at this level same information about the original sender. what do
you think about?

> 
> In any case, I think these should be dependent on the presence of a 
> store-and-forward server in the path.
> 
> 
> 
> /Miguel
> 
> 
> > 
> >> On the other hand, if there isn't a store-and-forward server in the

> >> path, then there is no need for the sender to receive additional 
> >> notifications, because the success reports in MSRP will do the job.
> >>
> >> So, I guess where we are going is to get some sort of conditional
IMDN 
> >> for MSRP. The condition being the unavailability of the recipient
to get 
> >> the messages and a store-and-forward server storing them. This will

> >> obviously apply to either large messages or short ones.
> > 
> > I don't have a clear view on this,
> > but maybe if we introduce a indication that an MRSP session is
> > established for just sending one message, this indication could
help.
> >> Any views on this?
> >> BR,
> >>       Miguel

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

---

From: "Nadia Bishai \(QA/EMC\)" <[email-masked]>
Date: Fri, 2 Mar 2007 08:37:46 -0500

Hi Matthew

In OMA we have just accepted a CR to add a feature tag for Large Message
mode. This will make it easier for both the client and the server to
distinguish between different session types.

Nadia Bishai 

-----Original Message-----
From: Stafford, Matthew [mailto:[email-masked]] 
Sent: March 1, 2007 5:02 PM
To: [email-masked]
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Best,
Matt Stafford

-----Original Message-----
From: Salvatore Loreto (JO/LMF) [mailto:[email-masked]]
Sent: Monday, February 05, 2007 7:40 AM
To: Miguel Garcia
Cc: Stafford, Matthew; [email-masked]'
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Miguel,

br
/sal

case 

or 
the 
can 
session 

use
off-line
do 

messages, 
SEND 
the
any

IMDN 
to get 

help.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2007 09:02:29 -0500

> distinguish between different session types.

A *feature tag* ???

Do you mean a callee-caps feature tag? Can you explain further how that 
will be used?

Feature tags describe *capabilities* that are supported or desired. They 
don't specify capabilities that are necessarily being *used*. And they 
apply to the UA, not to a particular media stream a UA might be using.

So, using a feature tag might be fine if it means "I have the capability 
to support large message mode". But it isn't fine if it is intended to 
mean "This INVITE is being used to establish a session using Large 
Message Mode".

	Paul

---

From: "Stafford, Matthew" <[email-masked]>
Date: Fri, 2 Mar 2007 14:35:58 -0600

Thx.

-----Original Message-----
From: Nadia Bishai (QA/EMC) [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 7:38 AM
To: Stafford, Matthew; [email-masked]
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Matthew

Nadia Bishai 

-----Original Message-----
From: Stafford, Matthew [mailto:[email-masked]] 
Sent: March 1, 2007 5:02 PM
To: [email-masked]
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Best,
Matt Stafford

-----Original Message-----
From: Salvatore Loreto (JO/LMF) [mailto:[email-masked]]
Sent: Monday, February 05, 2007 7:40 AM
To: Miguel Garcia
Cc: Stafford, Matthew; [email-masked]'
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Miguel,

br
/sal

case 

or 
the 
can 
session 

use
off-line
do 

messages, 
SEND 
the
any

IMDN 
to get 

help.

---

From: "Nadia Bishai \(QA/EMC\)" <[email-masked]>
Date: Wed, 7 Mar 2007 15:30:05 -0500

Hi

Actually we use it as a Caller Prefernce in the Accept-Contact header,
to indicate to the recipient preferred handling of the request.

Nadia 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: March 2, 2007 9:02 AM
To: Nadia Bishai (QA/EMC)
Cc: Stafford, Matthew; [email-masked]
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Nadia Bishai (QA/EMC) wrote:
> Hi Matthew
> 
> In OMA we have just accepted a CR to add a feature tag for Large 
> Message mode. This will make it easier for both the client and the 
> server to distinguish between different session types.

A *feature tag* ???

	Paul

> That concern led to the idea of: you'd need a way to distinguish 
> between large message mode and a "true" session based experience. 
> Jerry Shih's clarification at the time- regarding OMA's large message 
> mode
> definition- was that the large message originator's client would 
> specify send-only in the SDP session negotiation. So, if the intended 
> recipient

> and moreover MUST specify send-only if it wants to request DN. (Even 
> if a single message were chunked into multiple MSRP SENDs, I'm 
> assuming you wouldn't want to have DN headers in each chunk- I'm 
> thinking of the DN business as residing at a higher layer.)
> 

> It can say to the final recipient to send an IMDN to the original 
> sender when as soon as he has received the whole large message or all 
> the short messages. For example as soon the store and forward server 
> close the MSRP session.