Re: [sixpac] charter proposal

Emil Ivov <emcho@sip-communicator.org> Fri, 12 November 2010 04:55 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 85D043A68A5 for <sixpac@core3.amsl.com>; Thu, 11 Nov 2010 20:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 IXS3AAjx8eAJ for <sixpac@core3.amsl.com>; Thu, 11 Nov 2010 20:55:08 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 917F43A691F for <sixpac@ietf.org>; Thu, 11 Nov 2010 20:55:07 -0800 (PST)
Received: by gxk27 with SMTP id 27so1920102gxk.31 for <sixpac@ietf.org>; Thu, 11 Nov 2010 20:55:39 -0800 (PST)
Received: by 10.91.188.3 with SMTP id q3mr2585864agp.52.1289537737434; Thu, 11 Nov 2010 20:55:37 -0800 (PST)
Received: from porcinet.local (nsc64.16.130-178.newsouth.net [64.16.130.178]) by mx.google.com with ESMTPS id w3sm3196876anw.25.2010.11.11.20.55.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 20:55:35 -0800 (PST)
Message-ID: <4CDCC8C6.30404@sip-communicator.org>
Date: Thu, 11 Nov 2010 23:55:34 -0500
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.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Musgrave <peter.musgrave@magorcorp.com>
References: <4CDB9E64.6070704@stpeter.im> <4CDC1E19.7090208@sip-communicator.org> <B3F72E5548B10A4A8E6F4795430F841840CEE9EC27@NOK-EUMSG-02.mgdnok.nokia.com> <4CDC2683.1000005@sip-communicator.org> <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com>
In-Reply-To: <3A9C34EB-A3C6-4247-BFFF-BFAB7F6FB978@magorcorp.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 12 Nov 2010 04:55:16 -0000

На 11.11.10 18:18, Peter Musgrave написа:
> Hi,
> 
> I agree avoiding configuration is good.

Just so that we are clear there is no misunderstanding: we aren't
talking about generic client configuration or provisioning. I guess
discovery is probably a better term.

SIP and XMPP have discovery mechanisms and I simply don't see why SIXPAC
shouldn't, especially given that it could entirely reuse the other two.
We just need to state that this how things should happen.

> The email analogy does not ring true for me. You need to ask about
> POP, IMAP etc. because these are different protocols.

The analogy was mostly between SMTP and POP or SMTP and IMAP. From a
user perspective there is absolutely no good reason to have to configure
one protocol for sending and another one for receiving mails since they
are only using a single service: e-mail.

> We do not have
> that issue here...both have AORs intended to be globally reachable.

The issue is: user A wants to connect to example.com using SIXPAC. A's
user agent needs to know what addresses it should connect to. As a
matter of fact it would almost go without saying that the most
reasonable way of doing so is to use each protocol's default mechanism.

What we are talking about is a mere reminder and possibly a suggestion
of using the same credentials. The whole thing is so natural that I am
at a complete loss as to why people are so worried about it.

Emil
> (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