Re: [sixpac] Chartering...

Emil Ivov <emcho@sip-communicator.org> Wed, 02 February 2011 08:38 UTC

Return-Path: <emcho@sip-communicator.org>
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 6BAB23A6B75 for <sixpac@core3.amsl.com>; Wed, 2 Feb 2011 00:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 T33FqbYh1VVc for <sixpac@core3.amsl.com>; Wed, 2 Feb 2011 00:38:24 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 996FD3A7123 for <sixpac@ietf.org>; Wed, 2 Feb 2011 00:38:23 -0800 (PST)
Received: by ewy8 with SMTP id 8so4005094ewy.31 for <sixpac@ietf.org>; Wed, 02 Feb 2011 00:41:42 -0800 (PST)
Received: by 10.14.122.79 with SMTP id s55mr9460973eeh.32.1296636101977; Wed, 02 Feb 2011 00:41:41 -0800 (PST)
Received: from porcinet.local (87-126-226-239.btc-net.bg [87.126.226.239]) by mx.google.com with ESMTPS id t5sm18011531eeh.14.2011.02.02.00.41.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 00:41:41 -0800 (PST)
Message-ID: <4D4918C2.6090004@sip-communicator.org>
Date: Wed, 02 Feb 2011 10:41:38 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
References: <4CDB9E64.6070704@stpeter.im> <DD8B10B86502AB488CB2D3DB4C546E38E67FFE@008-AM1MPN1-004.mgdnok.nokia.com>
In-Reply-To: <DD8B10B86502AB488CB2D3DB4C546E38E67FFE@008-AM1MPN1-004.mgdnok.nokia.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: sixpac@ietf.org
Subject: Re: [sixpac] Chartering...
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: Wed, 02 Feb 2011 08:38:25 -0000

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

Cheers,
Emil


> 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 
> sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac
> 

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
emcho@sip-communicator.org                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31