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

["Salvatore Loreto (JO/LMF)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, January 31, 2007 3:37 AM
> To: [e-mail]; [e-mail]
> 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:[e-mail]] 
> >Sent: 31 January, 2007 00:15
> >To: [e-mail]
> >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 <[e-mail]>
> >> Hisham Khartabil <[e-mail]>
> >> 
> >> 
> >> Real-time Applications and Infrastructure Area Director(s):
> >> Jon Peterson <[e-mail]> Cullen Jennings 
> >> <[e-mail]>
> >> 
> >> Real-time Applications and Infrastructure Area Advisor:
> >> Jon Peterson <[e-mail]>
> >> 
> >> Technical Advisor(s):
> >> Jon Peterson <[e-mail]>
> >> 
> >> Mailing Lists:
> >> General Discussion: [e-mail]
> >> To Subscribe: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/simple
> >> 
> >
> >_______________________________________________
> >Simple mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/simple
> >
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple


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