Re: [sixpac] charter proposal

Peter Musgrave <peter.musgrave@magorcorp.com> Thu, 11 November 2010 23:17 UTC

Return-Path: <peter.musgrave@magorcorp.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 274823A635F for <sixpac@core3.amsl.com>; Thu, 11 Nov 2010 15:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level:
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 yLs2Sdi8QeJ3 for <sixpac@core3.amsl.com>; Thu, 11 Nov 2010 15:17:40 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6DB473A63CB for <sixpac@ietf.org>; Thu, 11 Nov 2010 15:17:40 -0800 (PST)
Received: by yxi11 with SMTP id 11so371653yxi.31 for <sixpac@ietf.org>; Thu, 11 Nov 2010 15:18:11 -0800 (PST)
Received: by 10.150.195.6 with SMTP id s6mr2696876ybf.261.1289517490971; Thu, 11 Nov 2010 15:18:10 -0800 (PST)
Received: from dhcp-408b.meeting.ietf.org (dhcp-408b.meeting.ietf.org [130.129.64.139]) by mx.google.com with ESMTPS id v8sm398480yba.2.2010.11.11.15.18.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 15:18:10 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="utf-8"
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <4CDC2683.1000005@sip-communicator.org>
Date: Fri, 12 Nov 2010 07:18:03 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com>
References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> <B3F72E5548B10A4A8E6F4795430F841840CEE9EC27@NOK-EUMSG-02.mgdnok.nokia.com> <4CDC2683.1000005@sip-communicator.org>
To: Emil Ivov <emcho@sip-communicator.org>
X-Mailer: Apple Mail (2.1082)
Cc: sixpac@ietf.org
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: Thu, 11 Nov 2010 23:17:42 -0000

Hi, 

I agree avoiding configuration is good. 

The email analogy does not ring true for me. You need to ask about POP, IMAP etc. because these are different protocols. We do not have that issue here...both have AORs intended to be globally reachable. (Ok, I'm not an XMPP wizard - does it get called an AOR?)

Regards, 

Peter Musgrave

On 2010-11-12, at 1:23 AM, Emil Ivov wrote:

> Hey Markus,
> 
> На 11.11.10 11:54, Markus.Isomaki@nokia.com написа:
>> Hi Emil,
>> 
>> We have discussed about the configuration a couple of times this
>> week. The problem was that no-one here could anymore explain what we
>> actually meant by that statement in the charter proposal. Both SIP
>> and XMPP clients have ways to get their configs automatically. In SIP
>> there is no widely supported standard for this instead a number of
>> proprietary solutions are used. > Now we do have the SIP Forum work as
>> basis, of course.
> 
> OK, well it seems to me that people are interpreting this as something
> far scarier that it actually needs to be. We are absolutely _not_
> talking about creating a provisioning framework here. This is simply
> about explaining how to look up the SIP and XMPP server of a sixpac
> account.
> 
> I thought we could achieve this by simply stating that sixpac clients
> should use 3263 and 3920[bis] for the sixpac domain in order to discover
> the SIP part of the service.
> 
> We could also advise service maintainers to make sure that clients would
> be able to authorize users against the SIP and XMPP sever with the same
> set of credentials, so that it would be safe for clients to actually try
> this. Of course clients would need to be prepared to also handle the the
> case where credentials turn out to be different.
> 
> This is probably all there is to it ...
> 
>> But when it comes to SIXPAC clients, what it is that we could do
>> beyond saying that for the SIP config they use whatever is used for
>> SIP and for XMPP whatever is used for XMPP? It may be problematic but
>> is it a bigger problem that say configuring two separate SIP and XMPP
>> clients?
> 
> The point is that users won't know what SIP is, what XMPP is and why it
> is that they need to configure two accounts for (what appears to them
> as) a single service.
> 
> Email has been crippled by this very problem for years. Of course no one
> really knows what SMTP, and IMAP, and POP are which is why when
> configuring your e-mail client you very often get presented with a list
> of providers to choose from. Of course, while this works to some extent
> for GMail and Yahoo! it does nothing to address the issue for all the
> other providers out there.
> 
> Cheers,
> Emil
>> 
>> Markus
>> 
>> 
>>> -----Original Message----- From: sixpac-bounces@ietf.org
>>> [mailto:sixpac-bounces@ietf.org] On Behalf Of ext Emil Ivov Sent:
>>> 11 November, 2010 18:47 To: Peter Saint-Andre Cc: sixpac@ietf.org 
>>> Subject: Re: [sixpac] charter proposal
>>> 
>>> Hey Peter,
>>> 
>>> На 11.11.10 02:42, Peter Saint-Andre написа:
>>>> 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.
>>> 
>>> Well, I thought we had agreed on this and was quite surprised to
>>> find out that for some unknown reason it was once again _the_ issue
>>> with the sixpac charter :).
>>> 
>>> Frankly, I never really understood what people were so worried
>>> about. What harm could it cause to have a statement that advises
>>> implementors how to lookup the SIP and XMPP services for a sixpac
>>> account?
>>> 
>>> Besides, how else would you make this work in generic clients?
>>> Should users always manually configure the XMPP server address and
>>> the SIP proxy address, port and transport?
>>> 
>>> Cheers, Emil
>>>> 
>>>> 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
>>>> 
>>>> - 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
>>> 
>>> _______________________________________________ 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
> 
> _______________________________________________
> sixpac mailing list
> sixpac@ietf.org
> https://www.ietf.org/mailman/listinfo/sixpac