Subject: Re: [dispatch] Charter proposal on combining SIP voice with XMPP IM and presence

From: "Smyth, Colm (Colm)" <[email-masked]>
Date: Wed, 30 Sep 2009 19:54:39 +0100

Hi,
 
I'm interested in contributing to this working group.
 
The charter looks good, I'd like to tweak or clarify some aspects of the
description.
 
I agree that it's useful to focus is on the user experience of a hybrid
SIP/XMPP client, and leave out aspects of protocol-level interworking
(for example to define how to achieve an end-to-end voice session
between an XMPP/Jingle client and a SIP voice endpoint).
 
1. addressing
A hybrid SIP/XMPP client must have addresses in both protocols, but it's
not clear to me that it's mandatory that a hybrid SIP/XMPP client must
be able to automatically learn the corresponding address of other users
in the other protocol. It may be sufficient in simple clients for the
user to manually associate the other address with one of their contacts.
The other address could be discovered in a shared directory, or in a
private contacts store. It might also define ways for a user to
"publish" their address in the other protocol (e.g. sending an XMPP
message that contains their SIP address), that might allow the client to
discover and (automatically or at the user's discretion) register that
address.
 
2. session correlation
This topic seems to be entirely around operations and elements in the
UI. It's not so much about sessions as about allowing some operations to
span the two protocols (e.g. create/join/exit a conference that spans
SIP voice and XMPP chat, or "escalating" a conference in one protocol to
include the other, or "downgrading" it to exclude the other).
 
3. presence
It would make sense to be able to change session in either protocol
based on activity in the other, at the discretion of the client and the
user. I agree with the view that the WG should exclude details of
protocol-level aspects, but to be useful, I think the WG should address
the user experience but also provide concrete guidelines on implementing
cross-protocol presence spanning or synchronization, including mapping
parts of an XMPP presence stanza to/from a (SIP) PIDF document. This
group should address if the SIP and XMPP endpoints are to be considered
as separate points of presence, or if they are to be 100% synchronized.
Ideally we would cover both scenarios (e.g. discrete PIDF <tuple>
elements and possibly a second XMPP session to a different resource for
the same JID).

Peter St Andre referred to several drafts that do relate to SIP/XMPP
protocol inter-working:

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media

I would also like to see these drafts progress to RFCs, but I think that
is outside the charter of this group. Related to presence, I would like
to see this group agree on a richer mapping than the one in Table 6 of
draft-saintandre-sip-xmpp-presence, specifically to define a standard
way to map bidirectionally between the different <show> states and PIDF
elements.
 
Colm.