Subject: [dispatch] Updated SIP and XMPP combined use charter proposal

From: <[email-masked]>
Date: Mon, 26 Apr 2010 12:22:11 +0200

Hi,

This got stuck in DISPATCH moderator queue due to too many recipients, so I'm forwarding it separately.

Markus

>-----Original Message-----
>From: Isomaki Markus (Nokia-CIC/Espoo) 
>Sent: 26 April, 2010 13:13
>To: Robert Sparks; 'ext Peter Saint-Andre'; 'ext Gonzalo 
>Camarillo'; [email-masked]; 'ext Elwell, John'; 
>[email-masked]'; [email-masked]'; 
>[email-masked]'; [email-masked]'; 
>[email-masked]'; [email-masked]'; 
>Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]'
>Cc: [email-masked]
>Subject: Updated SIP and XMPP combined use charter proposal
>
>Hi all,
>
>We held a DISPATCH mini-BoF on SIP and XMPP combined use back 
>at the November IETF with a fair amount of interest. A charter 
>proposal was discussed around December/January, and most 
>people on DISPATCH were happy with the outcome. After that the 
>activity has been limited but there have been discussions with 
>the ADs and some interested folks how the charter proposal 
>should be updated to make it more clear what the mini-WG would 
>be about, and especially what is out of scope. Several people 
>were asking me about the topic before or during Anaheim IETF 
>so I expect the interest for this is still relatively high and 
>we should go forward.
>
>Based on the feedback Simo and myself have drafted an updated 
>charter proposal, see below. 
>
>The use cases and requirements draft has also been updated:
>http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/
>
>Also, Emil and Enrico submitted a draft on provisioning BCP:
>http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/
>
>Please comment especially on the charter if it looks clear and 
>concise enough.
>
>Regards,
>	Markus 
>
>
>Combining SIP Voice and Video with XMPP IM and Presence 
>=======================================================
>
>Session Initiation Protocol (SIP) and Extensible Messaging and 
>Presence Protocol (XMPP) are both enjoying a widespread 
>deployment over the Internet. SIP was originally intended for 
>setting up real-time media sessions, while XMPP's roots are 
>with instant messaging (IM) and presence. While both protocols 
>have mushroomed in functionality, the real deployments still 
>correlate highly with their original scope; SIP is mostly used 
>for voice and video and for interconnect with circuit switched 
>telephony systems, while most of XMPP deployments offer IM and 
>presence services. So far the success with fully integrated 
>voice, video, IM and presence services with either SIP or XMPP 
>has been limited. 
>
>One approach to make the best out of this situation is to 
>integrate a SIP User Agent and an XMPP client into a single 
>application. The application would use SIP for voice and video 
>and XMPP for IM and presence. The best part of this approach 
>would be that no changes to existing SIP or XMPP server 
>infrastructures would be required, and there would be no 
>issues with interoperability between the integrated endpoints 
>and ordinary SIP- or XMPP-only endpoints. This would enable 
>incremental deployment, which is an important success factor. 
>In this "fully independent" form no new SIP or XMPP standards 
>extensions would be either needed.
>
>When two integrated SIP and XMPP endpoints communicate with 
>each other, it would be possible to make the user experience 
>even more seamless by making the two protocols more "aware" of 
>each other through minor protocol extensions. For instance an 
>incoming SIP voice call could be explicitly correlated with an 
>ongoing IM exchange, or XMPP presence could include explicit 
>SIP voice availability status. For the sake of deployment 
>feasibility, it would be mandatory for such protocol 
>extensions not to require any changes to SIP or XMPP server 
>implementations, and to remain backwards compatible with 
>non-updated SIP and XMPP endpoints. 
>
>The objective of this Working Group is to document best 
>practices and develop protocol extensions for combining SIP 
>based voice and video with XMPP based IM and presence such 
>that a unified user experience can be offered to end user. 
>
>Specifically, the WG will address the following use cases: 
>-    User identifier discovery; it should be possible for a 
>user to learn other user's SIP identifier based on her XMPP 
>identifier and vice versa for future use without needing to 
>engage in an active communication session with the other user. 
>Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is 
>out of scope of this Working Group. 
>-    Presence integration; it should be possible for user's 
>XMPP presence status to explicitly include her capability and 
>willingness for SIP based voice and video communication. It is 
>desired that only XMPP presence extension mechanisms described 
>in RFC3921 or its successor are used; presence format 
>translation and mapping are out of scope of this Working Group.
>-    Session or conversation capability discovery and 
>correlation; it should be possible to combine XMPP IM with SIP 
>voice and video communication between two endpoints so that 
>the endpoints can discover each others' capabilities and 
>explicitly relate the communication across the two protocols.  
>-    Provisioning; it should be possible to configure 
>integrated SIP and XMPP endpoints with as small extra burden 
>as possible compared to SIP- or XMPP-only endpoints, 
>especially if both SIP and XMPP are offered by the same 
>service provider. However, it is desired that no protocol 
>changes are needed for this. Also, cross-domain authentication 
>is out of scope of this Working Group.
>
>The protocol extensions developed in the WG must meet the 
>following criteria:
>-    The extensions must work without changes to SIP or XMPP 
>server infrastructures (including typical SIP B2BUAs), and 
>across SIP and XMPP deployments that are independent from each 
>other (such as that they are offered by two different 
>non-coordinated domains). 
>-    The extensions must not break backwards compatibility 
>with non-updated SIP and XMPP endpoints.
>
>The following is out of scope of the initial charter of the WG: 
>-    Multiparty communication, for instance the combined use 
>of SIP voice conferencing and XMPP IM chatrooms. 
>-    Advanced services such as SIP session transfer combined 
>with XMPP IM. 
>-    Protocol interworking, that is, translation gateways from 
>SIP to XMPP or vice versa. 
>-    New routing logic; the WG should rely on existing routing 
>mechanisms defined for SIP and XMPP, and not define 
>cross-domain routing for example in case when a user's SIP AOR 
>is known but that user is not registered for SIP service.
>
>Milestones
>
>Dec 2010 Use cases and protocol requirements document 
>submitted to IESG (Informational).
>
>Aug 2011 Document  defining mechanisms for discovering user's 
>SIP identifier based on her XMPP identifier submitted to IESG 
>(Standards Track).
>
>Aug 2011 Document defining XMPP presence extensions for SIP 
>voice and video communication capability and willingness 
>submitted to IESG (Standards Track).
>
>Aug 2011 Document defining protocol extensions that allow 
>combined SIP voice and video and XMPP IM capable endpoints to 
>discover each others' capabilities and correlate their 
>communication across the two protocols submitted to IESG 
>(Standards Track).
>
>Aug 2011 Document defining best practises document for 
>configuration and provisioning of combined SIP and XMPP 
>endpoints submitted to IESG (BCP).