Re: [sixpac] charter proposal

["Charles Eckel (eckelcu)" <[e-mail]>]

Please see some minor comments on the charter inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Peter Saint-Andre
> Sent: Thursday, November 11, 2010 3:42 PM
> To: [e-mail]
> Subject: [sixpac] charter proposal
> 
> To kick off discussion, here is the charter as I sent it to the
> [e-mail] list a while back, with removal of a clause about
> working on user configuration, which I think is a large rathole.
> 
> Let's discuss and get busy!
> 
> /psa
> 
> =========================================================================
> 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

This is not realistic and I doubt it is what was truly meant. I think being backward-compatible with all applicable SIP and XMPP specifications or RFCs is more accurate.

> - Work without changes to deployed infrastructure such as existing
>   SIP and XMPP servers, B2BUAs, firewalls, etc.

Here as well, it may worth expanding to "deployed , standards compliant, infrastructure ..."

Cheers,
Charles


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