Re: [sixpac] charter proposal

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

Return-Path: <eckelcu@cisco.com>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D1428C129 for <sixpac@core3.amsl.com>; Fri, 12 Nov 2010 01:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.399
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqWCD80BJqeN for <sixpac@core3.amsl.com>; Fri, 12 Nov 2010 01:14:51 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D44C628C124 for <sixpac@ietf.org>; Fri, 12 Nov 2010 01:14:51 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; 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 sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2010 09:15:24 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAC9FOL3018187; Fri, 12 Nov 2010 09:15:24 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com 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: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C029B586F@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <4CDB9E64.6070704@stpeter.im>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sixpac] charter proposal
Thread-Index: AcuBdA1sFECsEJybS0aIkyBki4pc5QA1N8HQ
References: <4CDB9E64.6070704@stpeter.im>
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, sixpac@ietf.org
X-OriginalArrivalTime: 12 Nov 2010 09:15:23.0764 (UTC) FILETIME=[23101B40:01CB824A]
Subject: Re: [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: Fri, 12 Nov 2010 09:14:52 -0000

Please see some minor comments on the charter inline.

> -----Original Message-----
> From: sixpac-bounces@ietf.org [mailto:sixpac-bounces@ietf.org] On Behalf Of Peter Saint-Andre
> Sent: Thursday, November 11, 2010 3:42 PM
> To: sixpac@ietf.org
> Subject: [sixpac] charter proposal
> 
> 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!
> 
> /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)