[sixpac] Chartering...

[<[e-mail]>]

Hi all,

What comes to the SIXPAC charter proposal, the latest version (from November) is included below.

I think there was a pretty good agreement on this version, but I think there are three specific issues about it:

1. Is there enough energy to get the work done?

I don't know how many people are on this list (Peter, any estimate?), but there were enough people who *said* they want to get this done. I guess now the best way to show commitment and make progress is to review the Requirements and Use Cases draft (see my earlier mail) and send comments on it.

2. The client configuration part was dropped. Is that OK?

There was not really a common understanding on what the group would do, so the text was prone to misunderstandings. I don't think anyone's intention was to design something completely new just for SIXPAC clients. SIP has certain auto-config methods (such as the recent SIP Forum / IETF standard), and so does XMPP. If we see it useful to recommend something about their use by SIXPAC clients, I think we can do so along these lines (as included in the charter proposal now):

>the group may also define best practices related to the
>implementation and deployment of dual-stack SIP/XMPP endpoints.

3. Correlation and SIP deployment reality (B2BUAs, SBCs, ...)

Some people think that the "correlation between an XMPP IM session and a SIP voice or video session" is only going to work in "standards compliant" SIP networks, which may not exist due to the excessive deployment of SBCs and other types of B2BUA, who strip out or override end-to-end data between SIP UAs. This is certainly a risk, but fortunately I think in most cases the correlation is just an optimization/nice-to-have feature, and even if it fails on some or even most sessions, we will not ruin the user experience (it will be anyway better with SIXPAC than completely isolated SIP and XMPP clients). In the end I think we should here only worry about user experience, not get into the philosophical discussion about SBCs. We should also make sure our correlation method is straight-to-the-purpose (SIXPAC) and not some kind of generic framework a la session id or splices or something like that, that will open doors to all kinds of conspiracy theories what it can also be used for.

So, from my perspective the charter text is good (enough) as it is now, and we only need to worry about point 1 (track record so far has not been that impressive due to various reasons).

Any comments? Have I missed other issues/ratholes about the charter?

Markus 


>
>========================================================================
>=
>SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
>========================================================================
>=
>
>Problem Statement
>
>Both the Session Initiation Protocol (SIP) and the Extensible Messaging
>and Presence Protocol (XMPP) are widely deployed technologies for real-
>time communication over the Internet.  In order to offer a complete
>suite of features as well as communication across multiple networks,
>several user-oriented software applications support both SIP and XMPP,
>and more software developers have expressed interest in building such
>"dual-stack" solutions.  Unfortunately, it is difficult to provide a
>good end-user experience in such applications because SIP and XMPP are
>not "aware" of each other.  For example:
>
>- XMPP presence does not include availability states related to a SIP
>  voice call or video call (e.g., "on the phone"), thus preventing an
>  a dual-stack endpoint from showing presence-based communication hints
>
>- There is no correlation between an XMPP IM session and a SIP voice
>  or video session, thus preventing a dual-stack endpoint from providing
>  integrated user interfaces and communications history
>
>- SIP accounts and XMPP accounts are not directly correlated in contact
>  lists or vCards (and not all deployed services support storage of such
>  information), thus preventing a dual-stack endpoint from knowing that
>  a contact has both SIP and XMPP capabilities
>
>Although some proprietary solutions exist to the foregoing problems, it
>would be preferable to define standardized solutions for the sake of
>improved interoperability.
>
>Objectives
>
>Because both SIP and XMPP are easily extended through new SIP headers
>and XMPP elements, it should be possible to provide tighter integration
>within dual-stack SIP/XMPP user agents to improve the user experience.
>
>Any such extensions should meet the following criteria:
>
>- Be completely optional and backwards-compatible for all endpoints
>
>- Work without changes to deployed infrastructure such as existing
>  SIP and XMPP servers, B2BUAs, firewalls, etc.
>
>The SIXPAC WG will define a small number of SIP and XMPP extensions to
>solve the following use cases in dual-stack endpoints:
>
>- Including SIP-based availability states in XMPP presence (limited to
>  basic presence and availability states only, not the full range of
>  PIDF extensions)
>
>- Correlating an XMPP IM session with a SIP voice/video session, and
>  vice-versa
>
>- Advertising a SIP account address over XMPP and an XMPP account
>  address over SIP
>
>Additional use cases are out of scope, including anything related to or
>requiring server integration, multiparty communication, SIP-based IM and
>presence, XMPP-based voice and video, file transfer, generalized service
>discovery and capabilities exchange, full protocol translation in
>communication gateways, shared credentials across both SIP and XMPP
>accounts, rich presence extensions for features such as geolocation,
>etc. Although such topics are important and interesting, they are out of
>scope for this group.
>
>However, in addition to the protocol extensions explicitly mentioned
>above, the group may also define best practices related to the
>implementation and deployment of dual-stack SIP/XMPP endpoints.
>
>Deliverables
>
>- Use cases and protocol requirements
>
>- XMPP presence extension for SIP-based availability states
>
>- Media session correlation extensions for SIP and XMPP
>
>- Contact address advertisement extensions for SIP and XMPP
>
>- Best practices for implementation and deployment of dual-stack
>  endpoints
>
>Milestones
>
>Feb 2011  Submit use cases and protocol requirements document to IESG
>(Informational)
>
>Oct 2011  Submit XMPP presence extension document to IESG (Standards
>Track)
>
>Oct 2011  Submit media session correlation extensions document to IESG
>(Standards Track)
>
>Oct 2011  Submit contact address advertisement extension document to
>IESG (Standards Track)
>
>Oct 2011  Submit best practices document to IESG (Informational)
>