Subject: [dispatch] proposed SIXPAC charter

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 14:16:56 -0600

Earlier this year, some folks in the RAI area proposed an initiative to
define a few small extensions to both SIP and XMPP that would make it
easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on
feedback provided on the DISPATCH list and received from the RAI ADs,
I've taken the liberty of rewriting the proposed charter, in the hopes
that fresh text will spur a more conclusive discussion. I'm mostly just
trying to help the proponents put their best foot forward, so if folks
here have more feedback I'd expect that people like Simo Veikkolainen
and Emil Ivov will be able to engage in further discussion.

/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,
including topics such as user agent configuration.

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)

###

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Oct 2010 09:45:49 +0200

I find this a worthwhile topic to pursue. I had been wondering whether this activity would turn out to be more of a profiling exercise, and whether the IETF might not be the best choice of venue for such work. From the current draft charter it looks like there will be at least some protocol extension work, for which I believe the IETF is the correct venue. On the other hand, the Unified Communications Interoperability Forum (UCIF) is seeking to advance the state of play on XMPP interoperability, and if we were just talking about a profile or BCP, that might have been a better venue. Perhaps the IETF should focus on requirements and protocol extensions, and consider whether the BCP work would be better done elsewhere. Or at least, there should be some coordination with other activities relating to XMPP interoperability.

John  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: 19 October 2010 21:17
> To: [email-masked]
> Subject: [dispatch] proposed SIXPAC charter
>

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 20 Oct 2010 06:38:33 -0400

I also think this is a worthwhile topic.

I understand John's reservation about just doing profile work - although I
would prefer if this was done elsewhere it be be in an open forum (it's my
understanding UCIF is a 'paying members only' organization).

Peter Musgrave

On Wed, Oct 20, 2010 at 3:45 AM, Elwell, John <
[email-masked]> wrote:

> I find this a worthwhile topic to pursue. I had been wondering whether this
> activity would turn out to be more of a profiling exercise, and whether the
> IETF might not be the best choice of venue for such work. From the current
> draft charter it looks like there will be at least some protocol extension
> work, for which I believe the IETF is the correct venue. On the other hand,
> the Unified Communications Interoperability Forum (UCIF) is seeking to
> advance the state of play on XMPP interoperability, and if we were just
> talking about a profile or BCP, that might have been a better venue. Perhaps
> the IETF should focus on requirements and protocol extensions, and consider
> whether the BCP work would be better done elsewhere. Or at least, there
> should be some coordination with other activities relating to XMPP
> interoperability.
>
> John
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 21 Oct 2010 18:53:56 +0200

Hey folks,

На 20.10.10 09:45, Elwell, John написа:
> I find this a worthwhile topic to pursue. I had been wondering
> whether this activity would turn out to be more of a profiling
> exercise, and whether the IETF might not be the best choice of venue
> for such work. From the current draft charter it looks like there
> will be at least some protocol extension work, for which I believe
> the IETF is the correct venue. On the other hand, the Unified
> Communications Interoperability Forum (UCIF) is seeking to advance
> the state of play on XMPP interoperability, and if we were just
> talking about a profile or BCP, that might have been a better venue.

As you mention yourself, it is likely that the charter would involve
extension work that could lead to, for example, new SIP headers. These
are undoubtedly best handled here.

Cheers,
Emil

> Perhaps the IETF should focus on requirements and protocol
> extensions, and consider whether the BCP work would be better done
> elsewhere. Or at least, there should be some coordination with other
> activities relating to XMPP interoperability.
> 
> John
> 
>> -----Original Message----- From: [email-masked] 
>> Sent: 19 October 2010 21:17 To: [email-masked] Subject:
>> [dispatch] proposed SIXPAC charter
>> 
>> Earlier this year, some folks in the RAI area proposed an 
>> initiative to define a few small extensions to both SIP and XMPP
>> that would make it easier to develop and deploy dual-stack SIP+XMPP
>> endpoints. Based on feedback provided on the DISPATCH list and
>> received from the RAI ADs, I've taken the liberty of rewriting the
>> proposed charter, in the hopes that fresh text will spur a more
>> conclusive discussion. I'm mostly just trying to help the
>> proponents put their best foot forward, so if folks here have more
>> feedback I'd expect that people like Simo Veikkolainen and Emil
>> Ivov will be able to engage in further discussion.
>> 
>> /psa
>> 
>> ###
>> 
>> 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 
>> - 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.
>> 
>> 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
>> 
>> 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, including topics such as user agent configuration.
>> 
>> Deliverables
>> 
>> Oct 2011  Submit media session correlation extensions document to
>> IESG (Standards Track)
>> 
>> Oct 2011  Submit contact address advertisement extension document
>> to IESG (Standards Track)
>> 
> _______________________________________________ dispatch mailing
> list [email-masked] 

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: Dan York <[email-masked]>
Date: Tue, 26 Oct 2010 20:56:37 -0400

I definitely support this work.  I've been involved lately in several instances where both SIP and XMPP were included on the client side.  Any work that can help make the user experience more positive would be a good thing.

Regards,
Dan

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork  

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: Schumann Sebastian <[email-masked]>
Date: Wed, 27 Oct 2010 09:00:24 +0200

Dear all, Peter,
I think this initiative is touching some very actual problem, I second it as well.

One question: Would you think that this interaction between SIP and XMPP would also be targeted not only by dual-stack clients but also on the network side?
That is, having a SIP based telephony infrastructure (w/o SIP presence) with certain users and a XMPP based IM/P network  (w/o Jingle) with the same users? Having a mechanism of mapping the users in both networks, XMPP presence could be enhanced with SIP based telephony states. Would you see this in scope or rather out of scope of your proposal?

Thanks.
Sebastian

> initiative to
> =============================================================
>
> Problem Statement
>
> Messaging
> problems, it

---

From: Emil Ivov <[email-masked]>
Date: Wed, 27 Oct 2010 20:22:23 +0300

Hey Sebastian,

На 27.10.10 10:00, Schumann Sebastian написа:
> Dear all, Peter, I think this initiative is touching some very actual
> problem, I second it as well.
> 
> One question: Would you think that this interaction between SIP and
> XMPP would also be targeted not only by dual-stack clients but also
> on the network side? That is, having a SIP based telephony
> infrastructure (w/o SIP presence) with certain users and a XMPP based
> IM/P network  (w/o Jingle) with the same users? Having a mechanism of
> mapping the users in both networks, XMPP presence could be enhanced
> with SIP based telephony states. Would you see this in scope or
> rather out of scope of your proposal?

> to basic presence and availability states only, not the full range

Is this what you mean or did I miss something?

Cheers,
Emil

> Thanks. Sebastian
>> headers and XMPP elements, it should be possible to provide
>> tighter integration within dual-stack SIP/XMPP user agents to
>> improve the user experience.
>>

---

From: Schumann Sebastian <[email-masked]>
Date: Thu, 28 Oct 2010 10:53:31 +0200

Dear Emil

The charter mentions "dual-stack clients" and that server integration is out of scope.

What you stated is basically what I meant. However, not in regard to dual-stack clients but separate clients in both networks. That is, using e.g., a SIP hard phone and an XMPP communicator "separately" while still having the chance to merge the SIP based states in XMPP.

I think that this seems only possible involving infrastructure (which is initially excluded). One possibility is, e.g., generating and interpreting SIP SIMPLE dialoginfo information w/o client involvement. This is complex and should be indeed excluded I agree here. But in the end this might re-use exactly those definitions in XMPP to display a SIP phone call that are being defined by the charter. The interaction is however different from the your proposal.

Another more related option could be the SIP hard phone adding potential additional headers (that are in scope to be defined in the charter), extracting them on a SIP proxy and using a hidden XMPP client instance on server side to "add" this state information as a new resource (e.g., SIP-Phone). 
In principle, I see this similar (to a certain extend) to what the charter suggests already. All information that both stacks in the clients exchange (correlated states, identities in the respective other stack) should be anyways carried in an extension of each protocol as I understood. Only the "hidden interaction" of the dual stack client between SIP and XMPP would be defined as well so this "functionality" can also be implemented out of the clients as separate network entity. This would be the only extension I see worth considering.

Best regards
Sebastian 

> From: Emil Ivov [mailto:[email-masked]]
> Sent: Wednesday, 27. October 2010 19:22
> To: Schumann Sebastian
> Cc: Peter Saint-Andre; [email-masked]
> Subject: Re: [dispatch] proposed SIXPAC charter
> 
> Hey Sebastian,
>