Re: [Telepathy] Empathy, SIP, and XMPP



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/7/13 3:50 PM, Travis Reitter wrote:
On Mon, 2013-01-07 at 11:51 -0700, Peter Saint-Andre wrote:
Given that Empathy has both SIP and XMPP support, it would be
great if one of the Empathy developers could provide feedback on
a short spec we've been working on at the IETF about dual-stack
clients:

http://tools.ietf.org/html/draft-ivov-xmpp-cusax-02

Even a quick "looks mostly sane" would be appreciated.

Hi Peter,

Hi Travis. A very belated thanks for your feedback!

I thought I'd add some thoughts as someone who works with contact 
aggregation in the Folks client library [1] that the Gnome Desktop
uses. Our main backends provide support for Evolution addressbook
and Telepathy contacts (though we have a few other backends as
well).

" In order for CUSAX to function properly, XMPP service
administrators should make sure that at least one of the vCard
[RFC6350] "tel" fields for each contact is properly populated with
a SIP URI or a phone number when an XMPP protocol for vCard storage
(e.g., [XEP-0054] or [XEP-0292]) is used.

...

When receiving SIP calls, clients may wish to determine the
identity of the caller and bind it to a roster entry so that users
could revert to chatting or other forms of communication that
require XMPP. To do so clients could search their roster for an
entry whose vCard has a "tel" field matching the originator of the
call. "

Folks aggregates people at the simplest level by finding matching 
(trustworthy) identifying details amongst contacts. So, if user has
a local vCard contact with X-JABBER:alice example org and the XMPP
contact alice example org, Folks will present them at the highest
level as a single metacontact with their aggregate features and
contacts, the most-relevant avatar, full name, etc.

We don't currently automatically link on an XMPP's "tel" field
because we can't necessarily trust the "tel" field of the contact;
if a malicious user set their XMPP account's "tel" field to another
person's SIP account, they could potentially spoof that person's
identity and initiate or receive text communication as that other
person.

But if we had some means to verify the connection between a SIP and
XMPP contact, then we could link them together and present them as
a single person. Eg, if the SIP contact had a reference to the XMPP
contact, like an X-JABBER vCard field set to the XMPP contact's
JID, Folks or other clients could reasonably link them together.
For a malicious user to set up both links, they'd need control over
at least one of the victim's accounts, at which point, there would
be nothing we could do to help anyhow.

In an ideal world, both contacts would have the same verifiable
identity certificate, but I don't foresee that ever being common
enough for us to support. Client certificate management is just too
much of a hassle for all but the most technical and motivated of
users.

A similar real-world case is Facebook users available over XMPP.
Even if they provide VoIP or chat contact details, we can't link to
any matching contacts on that basis because Facebook doesn't verify
any user-set addresses.

Emil has already incorporated much of your feedback into the spec, but
I've also just added the second sentence to the following paragraph:

        In addition to discovering phone numbers from vCards, clients
        may also check for alternative communication methods as
        advertised in XMPP presence broadcasts and Personal
        Eventing Protocol nodes as described in <xref target="XEP-0152">
        XEP-0152: Reachability Addresses</xref>.  However, these
        indications are merely hints, and a receiving client ought not
        associate a SIP address and an XMPP address unless it has some
        way to verify the association (e.g., the vCard of the XMPP
        account lists the SIP address and the vCard of the SIP account
        lists the XMPP address).

(I've also corrected the spelling of your last name.)

" An alternate mechanism would be for CUSAX clients to add to "

Not relevant to folks, but this section seems to have been
truncated.

Yes, we've published several versions of the document since then. The
latest (published April 4) is here:

http://tools.ietf.org/html/draft-ivov-xmpp-cusax-04

Again, many thanks for taking the time to provide your feedback!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRfypaAAoJEOoGpJErxa2ppW0P/jYJxm14d5zUDNgXzp1ZSayK
BJA6UMiuSHsRToU//Cf6jNWZ/1cWlUhe1oArDiXXLkMQMccChMo/jy6eFW5tJGIW
dii/LvhdkM41H0kiLsBQnoYQSAp+xvTFw3vwJj+Wl3LAj6L6YrSbmWDErllytza1
IUUdBelA4FNGcf4yPiOyiB11dFQ2gnneX8bZ6S7dX/Ci6XALzL/30ntfUpADvJY9
GZuZIFmU8JW1YH6FrYbwEdjfpxvReKEbiOZwwOiFmKN3Rl8dkaQdu4GRsT3dWI2l
DtAZid/srNLuwX65muMMjIkeQkw7r8WThd4VRybguMpZjeBRzzjT2iNzNO5TFQAA
xme2C0MW0+vGpr5AJIDGcyyNOysrgfVncyBF44DJWzCAK3iY3eu/FlvTEhr4CNth
NvTN/Odd2vY3knLg2aJna7ry9uKY5FRlvFNvrMiaAkcjB0V3ovO/eB+hUfUrvzUp
mFLovY4qOQNQSS71WUbynk/RQtZzvSJQUoP2BNeMD1s9B9L6U3R0rEUAOh+ohYJ+
o86+iN/XxMBmpn0HCNA33oCbfbQCeQSKR0R99vRgLW8/1E/HJ8bQoB/cp2Y6eXWj
SIkDkIYjl3BBwi+4hmhm1LicOICRd5GI/sQp3cVPgBH3JPRf4v/t3rG81IXLdx2k
+c+TX4RUn8vTkK5hetZI
=qPnB
-----END PGP SIGNATURE-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]