Re: [sixpac] charter proposal

"Charles Eckel (eckelcu)" <> Fri, 12 November 2010 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9D1428C129 for <>; Fri, 12 Nov 2010 01:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.399
X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqWCD80BJqeN for <>; Fri, 12 Nov 2010 01:14:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D44C628C124 for <>; Fri, 12 Nov 2010 01:14:51 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOuT3EyrR7Ht/2dsb2JhbACDPJ44WnGiaYozkHSBIoFiCIFLcwSEWokP
X-IronPort-AV: E=Sophos;i="4.59,186,1288569600"; d="scan'208";a="285058301"
Received: from ([]) by with ESMTP; 12 Nov 2010 09:15:24 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id oAC9FOL3018187; Fri, 12 Nov 2010 09:15:24 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 01:15:23 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 12 Nov 2010 01:15:21 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [sixpac] charter proposal
Thread-Index: AcuBdA1sFECsEJybS0aIkyBki4pc5QA1N8HQ
References: <>
From: "Charles Eckel (eckelcu)" <>
To: "Peter Saint-Andre" <>, <>
X-OriginalArrivalTime: 12 Nov 2010 09:15:23.0764 (UTC) FILETIME=[23101B40:01CB824A]
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: Fri, 12 Nov 2010 09:14:52 -0000

Please see some minor comments on the charter inline.

> -----Original Message-----
> From: [] On Behalf Of Peter Saint-Andre
> Sent: Thursday, November 11, 2010 3:42 PM
> To:
> Subject: [sixpac] charter proposal
> 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.
> 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 ..."


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