[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]

Paul Witty paulrw at codian.com
Thu Jan 21 11:14:48 UTC 2010

Peter Saint-Andre wrote:
> Back before we even developed Jingle, I had some similar thoughts. It
> would be great if I could ask my server to call you (like a switchboard
> operator in the olden days), but realistically sometimes the client does
> know best (it's behind a firewall, it has certain network interfaces, it
> has certain capabilities, etc.). I do think it's worth exploring how
> much servers can do, because in many ways we've gotten away from the
> philosophy of "simple clients, complex servers". Is that philosophy
> really valid and sustainable? Should servers really do more, or should
> they be XML routers in the middle? Should the network be smart or dumb?
> These are large design questions and I don't think they have easy answers.
As I think I talked to a few people about in Brussels last year, I'm 
very interested in working on how we can put more call-control 
intelligence into the server.  It's not a simple case of "server knows 
best" or "client knows best": the server is better placed to know what 
resources people have online, and can do neat things like enabling a 
call to someone whose presence you haven't subscribed to without 
necessarily leaking their presence.  On the other hand, the client knows 
what codecs it has, what network interfaces it has available, and how it 
might be possible to contact them through ICE.

So I'm strongly in favour of a hybrid approach.  Like with sending 
messages, you can initiate a Jingle session (like a chat session) to the 
bare JID; this is handled by the server, which then uses its knowledge 
of the far end's presence to route the initiate session to the 
appropriate resources.  Only when the far end gives a positive response 
does the caller get a full JID with which to communicate, and at this 
point the server no longer needs to be in the loop for messages.



More information about the Standards mailing list