[sixpac] charter proposal

Peter Saint-Andre <stpeter@stpeter.im> Thu, 11 November 2010 07:42 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 20FEA3A6827 for <sixpac@core3.amsl.com>; Wed, 10 Nov 2010 23:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id bfv8F6FyxnX9 for <sixpac@core3.amsl.com>; Wed, 10 Nov 2010 23:42:08 -0800 (PST)
Received: from stpeter.im (stpeter.im []) by core3.amsl.com (Postfix) with ESMTP id 07F8A3A68A7 for <sixpac@ietf.org>; Wed, 10 Nov 2010 23:42:05 -0800 (PST)
Received: from dhcp-710a.meeting.ietf.org (dhcp-710a.meeting.ietf.org []) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 87C5640BB9 for <sixpac@ietf.org>; Thu, 11 Nov 2010 00:51:56 -0700 (MST)
Message-ID: <4CDB9E64.6070704@stpeter.im>
Date: Thu, 11 Nov 2010 15:42:28 +0800
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: sixpac@ietf.org
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040207050605030706070302"
Subject: [sixpac] charter proposal
X-BeenThere: sixpac@ietf.org
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." <sixpac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sixpac>
List-Post: <mailto:sixpac@ietf.org>
List-Help: <mailto:sixpac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2010 07:42:09 -0000

To kick off discussion, here is the charter as I sent it to the
dispath@ietf.org 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!


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.


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

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


- 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


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)