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

From: "Shih, Jerry" <[email-masked]>
Date: Mon, 5 Feb 2007 08:11:39 -0500

Actually, in OMA LARGE message definition, it is a one direction
(send-only) session, not really a regular MSRP session; so no chat in
this case. It is used as a one-shot message and the only reason it needs
to set-up a session is because it is over the MESSAGE method size. The
sending UE knows (but the user will not know that) that it is a one-time
message when it sets up the session (send-only).

Jerry Shih
Cingular Wireless, now the new AT&T
+1 404.236.5902 (Office)
+1 678.925.3568 (Mobile)

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

Hi ,

some comments in 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?)
> 
> 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.

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

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