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

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

One more comment about this, regarding use cases for "deferring" a whole
session: what it brings to my mind is a multiparty scenario where some
of my intended recipients are online and others are not. Those of us who
*are* online go ahead and have our chat; the result is stored; and those
who weren't available can sift through a "recording" of the session
later.

OMA actually defines a history function that can cover this use case,
among others. 

My main interest, at least to date, is basically feature parity between
page mode and large message mode- feature parity that extends to
deferred messaging use cases.

Best,
Matt

-----Original Message-----
From: Salvatore Loreto (JO/LMF) [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 7:02 AM
To: Miguel Garcia
Cc: Stafford, Matthew; [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

---

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 1 Mar 2007 17:00:19 -0600

That's the main thing we had in mind when we wrote the draft.

Best,
Matt

-----Original Message-----
From: Nancy Greene (QA/EMC) [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 12:59 AM
To: Miguel Garcia; Salvatore Loreto (JO/LMF)
Cc: [email-masked]
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

We can have CPIM in an MSRP SEND though, so that is where we should be
concentrating. Especially if we have this large message mode where only
one message is sent within the SIP session and that is the one that is
actually deferred.

Nancy 

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

Salvatore Loreto (JO/LMF) wrote:

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

I think it is not a straight forward option. At least, I would like to
re-use IMDN as much as possible. Including IMDN requests in INVITE
requests is not feasible today, since IMDN requests are embedded in CPIM
messages, and we don't have CPIM in INVITE requests.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Andrew Allen" <[email-masked]>
Date: Wed, 7 Mar 2007 16:52:52 -0500

Nadia

Is this feature tag being used as a service identifier? 

Does this feature tag also trigger routing to IM servers based on filter criteria?

Do SIP requests for MSRP sessions get rejected if the tag doesn't appear in Accept-Contact?

Is the tag used for charging and authorisation purpose?

Andrew

--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: Nadia Bishai (QA/EMC) <[email-masked]>
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Mar 07 15:30:05 2007
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

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

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

> Nadia Bishai
> From: Stafford, Matthew [mailto:[email-masked]]
> Sent: March 1, 2007 5:02 PM
> To: [email-masked]
> 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:

>> 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
> 
> Sent: Monday, February 05, 2007 7:40 AM
> To: Miguel Garcia
> Hi Miguel,
> see the discussion on line
> 
> br
> /sal
> 
>> 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.
> 
>>
>> 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.

>> In any case, I think these should be dependent on the presence of a 
>> store-and-forward server in the path.
>>
>>
>>
>> /Miguel
>>
>>
>>>> for MSRP. The condition being the unavailability of the recipient
> to get

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.