Re: [sixpac] charter proposal

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. 

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?

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