Subject: RE: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple)

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Mon, 05 Feb 2007 14:14:13 +0200

Hi,

-how continue (or better change) a conversation triggered by a MESSAGE
in a new MRSP session

-issues related to MRSP sessions established for just sending one
message (e.g. imdn or similar functionality)

I do think that both the issues summarized above (and mentioned in the
previous mails) are problems that SIMPLE should try to address.

br
sal

On Wed, 2007-01-31 at 08:48 -0600, Stafford, Matthew wrote:
> Re wireless service providers wanting something similar to MMS: I would
> say not only in its own right, but as an interworking vehicle with the
> MMS installed base. This is important, I think, from the POV of
> facilitating SIMPLE deployment- something I would very much like to see!
> 
> In the context of this conversation, I am eager to hear comments on an
> internet draft posted a couple of weeks ago:
> http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt
> 
> The draft sets forth use cases involving MSRP- use cases in which imdn
> (or similar) functionality would be very useful. In many instances, use
> cases can be supported with existing building blocks. But here we do see
> a gap, and think that the best solution would be a new/extended building
> block devised by IETF. As I indicated in a Jan 19 message posted to this
> list, we understand the need to go ahead and progress the imdn draft
> (sans MSRP).
> 
> I'm not necessarily inviting detailed discussion of this draft (in the
> midst of the current rechartering discussion, that might be premature).
> At this point, I'm wanting to know whether this sort of thing will be in
> scope (and "lobbying" for the answer to be yes...)
> 
> Best,
> Matt Stafford 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 3:37 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] Internal WG Review: Recharter of SIP
> forInstantMessaging and Presence Leveraging Extensions (simple)
> 
> Hi,
> 
> Yes, I think this is a feature that would be needed in practice. Having
> two messaging mechanisms without clear guidance on how they relate to
> each other is going to cause interoperability issues - if not on the
> protocol level then at least on the UI-to-UI or user-to-user level.
> 
> Another thing is that there should be some kind of
> specification/guideline on how to actually deliver one-shot messages
> that are larger than 1300 bytes. One way is to use MSRP, another to do
> content indirection with MESSAGE. In MSRP the key is the ability for the
> sender to indicate (at least as a preference/hint) that the session is
> established for just sending a single message, not to open a
> conversation. This is wanted by providers who would like to be able to
> offer something similar to MMS service on top of a SIP infra. 
> 
> SIMPLE WG has not been very enthusiastic about this in the past, so I
> think OMA has already defined a particular mechanism for MSRP. If
> everyone who is interested in this is anyway involved in OMA, as it
> seems, there would be not much value for IETF to do anything about it.
> However, if there is real interest outside OMA, it would be useful to
> have some work in SIMPLE WG.
> 
> Markus
>  
> 
> >-----Original Message-----
> >From: ext Paul Kyzivat [mailto:[email-masked]] 
> >Sent: 31 January, 2007 00:15
> >To: [email-masked]
> >Subject: Re: [Simple] Internal WG Review: Recharter of SIP for 
> >InstantMessaging and Presence Leveraging Extensions (simple)
> >
> >Wasn't there some talk of a need to specify how to choose 
> >between MESSAGE and MSRP, and/or to transition between them in 
> >support of a single conversation?
> >
> >E.g. send a MESSAGE because there may never be a conversation, 
> >but then INVITE with an MSRP session to continue the 
> >conversation. The need here would be for a way to tie these 
> >things together so it is clear that they are part of the same 
> >conversation. There are obviously issues with involving the 
> >same pair of UAs in both.
> >
> >I seem to recall this was discussed at some point, but I'm not 
> >sure and if so I don't remember the outcome.
> >
> >	Paul
> >
> >IESG Secretary wrote:
> >> A new charter for the SIP for Instant Messaging and Presence 
> >> Leveraging Extensions (simple) working group in the Real-time 
> >> Applications and Infrastructure Area of the IETF is being 
> >considered. 
> >> The draft charter is provided below for your review and comment.
> >> 
> >> Review time is one week.
> >> 
> >> The IETF Secretariat
> >> 
> >> +++
> >> 
> >> SIP for Instant Messaging and Presence Leveraging Extensions 
> >(simple) 
> >> 
> >======================================================================
> >> 
> >> Last Modified: 2007-1-24
> >> 
> >> Current Status: Active Working Group
> >> 
> >> Chair(s):
> >> Robert Sparks <[email-masked]>
> >> Hisham Khartabil <[email-masked]>
> >> 
> >> 
> >> Real-time Applications and Infrastructure Area Director(s):
> >> Jon Peterson <[email-masked]> Cullen Jennings 
> >> <[email-masked]>
> >> 
> >> Real-time Applications and Infrastructure Area Advisor:
> >> Jon Peterson <[email-masked]>
> >> 
> >> Technical Advisor(s):
> >> Jon Peterson <[email-masked]>
> >> 
> >> Mailing Lists:
> >> General Discussion: [email-masked]
> >> To Subscribe: [email-masked]
> >> In Body: subscribe
> >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html
> >> 
> >> Description of Working Group:
> >> 
> >> This working group focuses on the application of the Session 
> >> Initiation Protocol (SIP, RFC 3261) to the suite of services 
> >> collectively known as instant messaging and presence (IMP). The IETF 
> >> has committed to producing an interoperable standard for these 
> >> services compliant to the requirements for IM outlined in RFC 2779 
> >> (including the security and privacy requirements there) and in the 
> >> Common Presence and Instant Messaging (CPIM) specification, 
> >developed 
> >> within the IMPP working group. As the most common services for which 
> >> SIP is used share quite a bit in common with IMP, the adaptation of 
> >> SIP to IMP seems a natural choice given the widespread support for 
> >> (and relative maturity of) the SIP standard.
> >> 
> >> This group has completed the majority of its primary goals and will 
> >> focus on the remaining tasks documented here and concluding. Any 
> >> proposed new work should be socialized with the chairs and 
> >AD early to 
> >> determine if this WG is an appropriate venue.
> >> 
> >> The primary remaining work of this group will be to complete:
> >> 
> >> 1. The MSRP proposed standard mechanism for transporting sessions of 
> >> messages initiated using the SIP, compliant to the 
> >requirments of RFC 
> >> 2779, CPIM and BCP 41.
> >> 
> >> 2. The XCAP framework for representing and carrying 
> >configuration and 
> >> policy information in SIMPLE systems.
> >> 
> >> 3. A mechanism for representing partial changes (patches) to XML 
> >> documents and extensions to the SIMPLE publication and notification 
> >> mechanisms to convey these partial changes.
> >> 
> >> 4. A mechanism for initiating and managing Instant Message 
> >group chat.
> >> 
> >> 5. An annotated overview of the SIMPLE protocol definition documents.
> >> 
> >> Any SIP extensions proposed in the course of this development will, 
> >> after a last call process, be transferred to the SIP WG for 
> >> consideration as formal SIP extensions.
> >> 
> >> Any mechanisms created for managing Instant Message group chat are 
> >> intended to provide a bridge to the conferencing protocols that will 
> >> be defined in XCON. They will be limited in scope to address only 
> >> simple Instant Message chat with nicknames and will not attempt to 
> >> address complex conferencing concepts such as sidebars. Their design 
> >> must anticipate operating in conjunction with the conferencing 
> >> protocols XCON is working towards.
> >> 
> >> The working group will work within the framework for presence and IM 
> >> described in RFC 2778. The extensions it defines must also be 
> >> compliant with the SIP processes for extensions. The group cannot 
> >> modify baseline SIP behavior or define a new version of SIP 
> >for IM and 
> >> presence. If the group determines that any capabilities requiring an 
> >> extension to SIP are needed, the group will seek to define such 
> >> extensions within the SIP working group, and then use them here.
> >> 
> >> Goals and Milestones:
> >> Done Submission of event package for presence to IESG for 
> >publication 
> >> as Proposed Standard Done Submission of watcher information 
> >drafts to 
> >> IESG for publication as Proposed Standards Done Submission 
> >of proposed 
> >> event list mechanism to the SIP working group Done Submission of 
> >> requirements for event publishing to the IESG for publication as 
> >> Proposed Standard Done Submission of proposed mechanism for event 
> >> publishing to the SIP working group Done Submission of SIMPLE PIDF 
> >> profile to IESG for publication as Proposed Standard Done Submission 
> >> of base XCAP draft to IESG for publication as Proposed Standard Done 
> >> Submission of indication of instant message preparation using SIP to 
> >> IESG for publication as a Proposed Standard Done Submission of XCAP 
> >> usage for manipulation of presence document content Done 
> >Submission of 
> >> XCAP usage for setting presence authorization to IESG for 
> >publication 
> >> as Proposed Standard Done Submission of Filtering mechanisms to IESG 
> >> for publication as a Proposed Standard Done Submission of instant 
> >> messaging session draft to IESG for publication as a 
> >Proposed Standard 
> >> Done Submission of instant messaging session relay drafts to 
> >IESG for 
> >> publication as Proposed Standards Done Submission of Partial 
> >> Notification mechanism to IESG for publication as a Proposed 
> >Standard 
> >> Feb 2007 Submission of an Instant Message Disposition Notification 
> >> mechanism to the IESG for publication as a Proposed Standard 
> >Feb 2007 
> >> Submission of XCAP event package to IESG or appropriate 
> >working group 
> >> targeting publication as Proposed Standard Feb 2007 Submission of 
> >> proposed mechanisms meeting the advanced messaging 
> >requirements to the 
> >> IESG or appropriate working group Mar 2007 Submission of a 
> >performance 
> >> and scalability analysis of the SIMPLE presence mechanisms 
> >to the IESG 
> >> for publication as Informational Jun 2007 Submission of SIMPLE 
> >> protocol annotated overview draft to IESG for publication as 
> >> Informational Aug 2007 Submission of proposed mechanisms for 
> >> initiating and managing Instant Message group chat to the IESG for 
> >> publication as Proposed Standard Aug 2007 Conclusion of 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
> >
> 
> _______________________________________________
> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 15:34:56 -0500

I also think we need to deal with this.

This is one of a few cases where we have several solutions and not clear 
enough guidance on how to make it interoperate. What happens if one side 
supports MSRP, and the other, just MESSAGE? Do MSRP endpoints also need 
to do MESSAGE as a fallback? This is in addition to the questions around 
how and if to transition from MESSAGE to MSRP and so on.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com