Re: [sixpac] charter proposal

Emil Ivov <> Thu, 11 November 2010 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80BC53A6952 for <>; Thu, 11 Nov 2010 08:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OhzqD7YwM9qV for <>; Thu, 11 Nov 2010 08:46:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D02783A69FC for <>; Thu, 11 Nov 2010 08:46:53 -0800 (PST)
Received: by gxk27 with SMTP id 27so1468516gxk.31 for <>; Thu, 11 Nov 2010 08:47:23 -0800 (PST)
Received: by with SMTP id f14mr2041213ybm.319.1289494043433; Thu, 11 Nov 2010 08:47:23 -0800 (PST)
Received: from porcinet.local ( []) by with ESMTPS id v9sm7613ybe.21.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 08:47:22 -0800 (PST)
Message-ID: <>
Date: Thu, 11 Nov 2010 11:47:21 -0500
From: Emil Ivov <>
Organization: SIP Communicator
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sixpac] charter proposal
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Nov 2010 16:46:56 -0000

Hey Peter,

На 11.11.10 02:42, Peter Saint-Andre написа:
> To kick off discussion, here is the charter as I sent it to the
> list a while back, with removal of a clause about
> working on user configuration, which I think is a large rathole.

Well, I thought we had agreed on this and was quite surprised to find
out that for some unknown reason it was once again _the_ issue with the
sixpac charter :).

Frankly, I never really understood what people were so worried about.
What harm could it cause to have a statement that advises implementors
how to lookup the SIP and XMPP services for a sixpac account?

Besides, how else would you make this work in generic clients? Should
users always manually configure the XMPP server address and the SIP
proxy address, port and transport?

> 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
> - 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)
> _______________________________________________
> sixpac mailing list

Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator                     PHONE: +                    FAX:   +