Re: [sixpac] Chartering...

Emil Ivov <> Wed, 02 February 2011 08:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BAB23A6B75 for <>; Wed, 2 Feb 2011 00:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T33FqbYh1VVc for <>; Wed, 2 Feb 2011 00:38:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 996FD3A7123 for <>; Wed, 2 Feb 2011 00:38:23 -0800 (PST)
Received: by ewy8 with SMTP id 8so4005094ewy.31 for <>; Wed, 02 Feb 2011 00:41:42 -0800 (PST)
Received: by with SMTP id s55mr9460973eeh.32.1296636101977; Wed, 02 Feb 2011 00:41:41 -0800 (PST)
Received: from porcinet.local ( []) by with ESMTPS id t5sm18011531eeh.14.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 00:41:41 -0800 (PST)
Message-ID: <>
Date: Wed, 02 Feb 2011 10:41:38 +0200
From: Emil Ivov <>
Organization: SIP Communicator
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sixpac] Chartering...
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: Wed, 02 Feb 2011 08:38:25 -0000

На 01.02.11 14:42, написа:
> 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. 

Probably, yes.

> I don't think
> anyone's intention was to design something completely new just for
> SIXPAC clients.

Nope, indeed not. I am probably going to bring up the issue again once
we start designing the actual spec and I am quite confident that a few
lines recommending the use of standard SIP/XMPP discovery mechanisms
with SIXPAC would be just fine for everyone and compliant with the charter.


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

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