Subject: [sixpac] charter proposal

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Nov 2010 15:42:28 +0800

To kick off discussion, here is the charter as I sent it to the
[email-masked] list a while back, with removal of a clause about
working on user configuration, which I think is a large rathole.

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)

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Nov 2010 11:47:21 -0500

Hey Peter,

> 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
> _______________________________________________
> sixpac mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sixpac

-- 
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: <[email-masked]>
Date: Thu, 11 Nov 2010 17:54:02 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Emil Ivov
>Sent: 11 November, 2010 18:47
>To: Peter Saint-Andre
>Cc: [email-masked]
>Subject: Re: [sixpac] charter proposal
>
>Hey Peter,
>

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 18:06:18 +0100

Hi,

>  integrated user interfaces and communications history

It has been pointed out that in SIP we may have practical challenges to achieve this with a high likelihood. This means that if our solution is based on some kind of token that is exchanged between the two SIXPAC clients over SIP (so that they can replay it later on over XMPP for correlation), and if we put that token in some kind of a new header, it is possible that B2BUA's on the path will "eat" such headers out. So as a practical consideration we have to think about what happens if that kind of exchange fails.

>- Advertising a SIP account address over XMPP and an XMPP account

I don't think there is a reason to change our charter at all because of this, but this is perhaps something that we could cover in the use cases and requirements document.

Markus

>Of ext Peter Saint-Andre
>Sent: 11 November, 2010 09:42
>To: [email-masked]
>Subject: [sixpac] charter proposal
>
>and Presence Protocol (XMPP) are widely deployed technologies for real-
>time communication over the Internet.  In order to offer a complete
>Feb 2011  Submit use cases and protocol requirements document to IESG
>(Informational)
>
>Oct 2011  Submit XMPP presence extension document to IESG (Standards
>Track)
>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Nov 2010 12:23:15 -0500

Hey Markus,

На 11.11.10 11:54, [email-masked] написа:
> 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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ext Emil Ivov Sent:
>> 11 November, 2010 18:47 To: Peter Saint-Andre Cc: [email-masked] 
>>> [email-masked] 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
>>> 
>> ========================================================================
>>
>> 
=
>> ========================================================================
>>
>> 
=
>>> 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
>>> lists or vCards (and not all deployed services support storage
>>> of
>> such
>>> 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
>>> - 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
>>> 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
>>> 
>>> Oct 2011  Submit media session correlation extensions document to
>>> IESG (Standards Track)
>>> 
>>> Oct 2011  Submit contact address advertisement extension document
>>> to IESG (Standards Track)
>>> 
>>> _______________________________________________ sixpac 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
>> 
>> _______________________________________________ sixpac mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/sixpac

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 11 Nov 2010 14:06:08 -0500

Hi,

I too think that this group should avoid dealing with the configuration issue.

>the SIP part of the service.

I do not see how statements like "should use..." will help, as these types of statements are most of the time ignored anyway.

Regards,
 Rifaat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Thursday, November 11, 2010 12:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sixpac] charter proposal

Hey Markus,

Cheers,
Emil
=
=

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 12 Nov 2010 07:18:03 +0800

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Nov 2010 23:55:34 -0500

> 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
> 
>>> 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.
>> 
>>> 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
>>> 
>>> 
>>>> [mailto:[email-masked]] On Behalf Of ext Emil Ivov
>>>> Sent: 11 November, 2010 18:47 To: Peter Saint-Andre Cc:
>>>> [email-masked] Subject: Re: [sixpac] charter proposal
>>>> 
>>>> Hey Peter,
>>>> 
>>>>> To kick off discussion, here is the charter as I sent it to
>>>>> the [email-masked] 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 :).
>>>> 
>>>> 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?
>>>> 
>>>> Should users always manually configure the XMPP server address
>>>> and the SIP proxy address, port and transport?
>>>> 
>>>> Cheers, Emil
>>>>> 
=
=
>>>>> 
>>>>> 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
>>>>> 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
>>>>> - 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
>>>>> 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
>>>>> (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.
>>>>> 
>>>>> mentioned above, the group may also define best practices
>>>>> related to the implementation and deployment of dual-stack
>>>>> SIP/XMPP endpoints.
>>>>> 
>>>>> Deliverables
>>>>> 
>>>>> - 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 media session correlation extensions
>>>>> document to IESG (Standards Track)
>>>>> 
>>>>> Oct 2011  Submit contact address advertisement extension
>>>>> document to IESG (Standards Track)
>>>>> 
>>>>> _______________________________________________ sixpac
>>>>> mailing list [email-masked] 
>>>> 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: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 12 Nov 2010 01:15:21 -0800

Please see some minor comments on the charter inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Thursday, November 11, 2010 3:42 PM
> To: [email-masked]

This is not realistic and I doubt it is what was truly meant. I think being backward-compatible with all applicable SIP and XMPP specifications or RFCs is more accurate.

>   SIP and XMPP servers, B2BUAs, firewalls, etc.

Here as well, it may worth expanding to "deployed , standards compliant, infrastructure ..."

Cheers,
Charles