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

From: "Andrew Allen" <[email-masked]>
Date: Wed, 7 Mar 2007 18:08:27 -0500

Nadia

So is the feature tag +g.oma.sip-im is used as a service identifier then?

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: Andrew Allen; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Mar 07 18:01:12 2007
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Andrew, 

Please see answers below 

Nadia 

-----Original Message----- 
From: Andrew Allen [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: March 7, 2007 4:53 PM 
To: Nadia Bishai (QA/EMC); [email-masked] 
Cc: [email-masked] 
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt 

Nadia 

Is this feature tag being used as a service identifier? 
Nadia: Not in the sense of a communication service identifier used by 3GPP. But as an indication of desired treatment by the recipient.

Does this feature tag also trigger routing to IM servers based on filter criteria? 
Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im and/or the Request Type. 

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

Nadia: No 
Is the tag used for charging and authorisation purpose? 

Nadia: No 

Andrew 

-------------------------- 
Andrew Allen 
Manager Standards 
Research In Motion Ltd 
BlackBerry Mobile  +1 847 809 8636 
http://www.rim.com/ <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] <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 
> 
> -----Original Message----- 
> From: Stafford, Matthew [mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: March 1, 2007 5:02 PM 
> To: [email-masked] 
> Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt 
> 
> 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] <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 <https://www1.ietf.org/mailman/listinfo/simple>  
> 
> _______________________________________________ 
> Simple mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/simple <https://www1.ietf.org/mailman/listinfo/simple>  
> 

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

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

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

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

---

From: "Nadia Bishai \(QA/EMC\)" <[email-masked]>
Date: Thu, 8 Mar 2007 09:13:47 -0500

Hi

It is my understanding that the OMA feature tags are used to identify
the service.

nadia 

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: March 7, 2007 6:08 PM
To: Nadia Bishai (QA/EMC); [email-masked]
Cc: [email-masked]
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Nadia

So is the feature tag +g.oma.sip-im is used as a service identifier
then?

Andrew

----- Original Message -----
From: Nadia Bishai (QA/EMC) <[email-masked]>
To: Andrew Allen; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Mar 07 18:01:12 2007
Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

Hi Andrew, 

Please see answers below 

Nadia 

-----Original Message-----
From: Andrew Allen [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: March 7, 2007 4:53 PM
To: Nadia Bishai (QA/EMC); [email-masked]
Cc: [email-masked]
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt 

Nadia 

Is this feature tag being used as a service identifier? 
Nadia: Not in the sense of a communication service identifier used by
3GPP. But as an indication of desired treatment by the recipient.

Does this feature tag also trigger routing to IM servers based on filter
criteria? 
Nadia: No. Routing is based on other iFCs, namely the +g.oma.sip-im
and/or the Request Type. 

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

Nadia: No

Nadia: No 

Andrew 

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

A *feature tag* ??? 

        Paul 

messages. 

> <https://www1.ietf.org/mailman/listinfo/simple>
> 
> <https://www1.ietf.org/mailman/listinfo/simple>
> 

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

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

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