Re: [sixpac] charter proposal

Emil Ivov <> Fri, 12 November 2010 04:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85D043A68A5 for <>; Thu, 11 Nov 2010 20:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IXS3AAjx8eAJ for <>; Thu, 11 Nov 2010 20:55:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 917F43A691F for <>; Thu, 11 Nov 2010 20:55:07 -0800 (PST)
Received: by gxk27 with SMTP id 27so1920102gxk.31 for <>; Thu, 11 Nov 2010 20:55:39 -0800 (PST)
Received: by with SMTP id q3mr2585864agp.52.1289537737434; Thu, 11 Nov 2010 20:55:37 -0800 (PST)
Received: from porcinet.local ( []) by with ESMTPS id w3sm3196876anw.25.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 20:55:35 -0800 (PST)
Message-ID: <>
Date: Thu, 11 Nov 2010 23:55:34 -0500
From: Emil Ivov <>
Organization: SIP Communicator
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Musgrave <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sixpac] charter proposal
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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.

> (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, написа:
>>> 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: 
>>>> [] On Behalf Of ext Emil Ivov
>>>> Sent: 11 November, 2010 18:47 To: Peter Saint-Andre Cc:
>>>> 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 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 
>>>> -- Emil Ivov, Ph.D.                               67000 
>>>> Strasbourg, Project Lead
>>>> France SIP Communicator PHONE:
>>>> + FAX:
>>>> +