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
- Re: [sixpac] charter proposal Emil Ivov
- [sixpac] charter proposal Peter Saint-Andre
- Re: [sixpac] charter proposal Markus.Isomaki
- [sixpac] charter proposal - correlation between S… Markus.Isomaki
- Re: [sixpac] charter proposal Emil Ivov
- Re: [sixpac] charter proposal Shekh-Yusef, Rifaat (Rifaat)
- Re: [sixpac] charter proposal Peter Musgrave
- Re: [sixpac] charter proposal Emil Ivov
- Re: [sixpac] charter proposal Charles Eckel (eckelcu)
- Re: [sixpac] charter proposal - correlation betwe… Robert Sparks
- Re: [sixpac] charter proposal - correlation betwe… Peter Musgrave
- Re: [sixpac] charter proposal - correlation betwe… Peter Musgrave
- Re: [sixpac] charter proposal - correlation betwe… Simo.Veikkolainen
- Re: [sixpac] charter proposal - correlation betwe… Peter Musgrave
- Re: [sixpac] charter proposal - correlation betwe… Robert Sparks
- Re: [sixpac] charter proposal - correlation betwe… Peter Saint-Andre
- [sixpac] Chartering... Markus.Isomaki
- Re: [sixpac] Chartering... Emil Ivov