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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 09:05:21 -0500

Nadia Bishai (QA/EMC) wrote:
> Hi Andrew,
> Please see answers below

[snip]

> 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

I'm glad to see the answers above, except for one.

Is the iFC matching on +g.oma.sip-im done when it is present in an 
Accept-Contact header? Or as a capability in a Contact header?

If in Accept-Contact, can you explain in detail how that will be done so 
that it doesn't make an incorrect decision when Accept-Contact and 
Reject-Contact are used in complex ways?

	Thanks,
	Paul

> ----- 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
>>
>>  -----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
>>
>>  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_
>>
>>  _______________________________________________
>>  Simple mailing list
>>  [email-masked]
>>  _https://www1.ietf.org/mailman/listinfo/simple_
>>
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> _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.
> 

_______________________________________________
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:17:00 -0500

Hi Paul,

In answer to your question:  

This is not specified in the OMA IM specifications, since the
specifications only address the service layer, i.e., after the SIP/IP
core has triggered on the iFCs and sent the requests to the IM
Application server.

Nadia

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

[snip]

> 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?
> 
> Nadia: No

	Thanks,
	Paul

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

>>  Jerry Shih's clarification at the time- regarding OMA's large 
>> message  mode

>> >> you are right, if you have a store-and-forward in the path this is

>> >> a

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

>>  put at this level same information about the original sender. what 
>> do  you think about?
>>
>>
>>

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 10:05:25 -0500

> core has triggered on the iFCs and sent the requests to the IM

Not the answer I was looking for. IMO this is an important question, in 
that it impacts whether this method of encoding service ids is valid. So 
let me ask the question again another way:

- Is there any way of constructing an iFC to select an IM-specific 
application server based on presence of +g.oma.sip-im in a request, that 
will always correctly deduce whether the request will ultimately select 
a contact with the +g.oma.sip-im capability? (Even when the caller has 
used some complex combination of Accept-Contact and Reject-Contact headers.)

IMO this can't be done without imposing restrictions on the caller 
regarding how Accept-Contact and Reject-Contact are used. If using this 
method for specifying service ids imposes restrictions on the use of 
3841 then I think that needs to be made clear.

	Paul

---

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

The only answer I can give you is that when the SIP/IP core is
3GPP/3GPP2 IMS/MMD, the trigerring mechanism decribed there will be
followed.

Nadia 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: March 8, 2007 10:05 AM
To: Nadia Bishai (QA/EMC)
Cc: Andrew Allen; [email-masked]
Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt

used some complex combination of Accept-Contact and Reject-Contact
headers.)

	Paul

> If in Accept-Contact, can you explain in detail how that will be done 
> so that it doesn't make an incorrect decision when Accept-Contact and 

>>> overview of the discussion to date, followed by a question about 
>>> where  this leads:
>>>
>>>> or reads the message(s).
>>> incorporate DN requests in multiple MSRP messages in the same 
>>> session,  and moreover MUST specify send-only if it wants to request

>>> DN. (Even
>>>  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
>>>
>>>> real use case.
>>>> Certainly that is one possibility. Another one is to promote the 
>>>> IMDN request to the INVITE, and provide a "session-level" IMDN.
>>>  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?
>>>
>>>
>>>