Jabber (was Re: [Twisted-Python] Closing Jabber connection)

Ralph Meijer twisted at ralphm.ik.nu
Wed May 4 03:10:59 MDT 2005


On Tue, May 03, 2005 at 07:30:19PM -0400, Glyph Lefkowitz wrote:
> Ralph Meijer wrote:
> >On Tue, May 03, 2005 at 03:17:34PM -0500, Peter Saint-Andre wrote:
> >
> >>[..]
> >>
> >>As I said, I know of several folks in the Jabber community who
> >>are quite interested in building a reference XMPP/Jabber server
> >>in Python, and I'm wondering if Words is the place to point them.
> >
> >
> >Besides that, one could argue that XMPP/Jabber doesn't belong in Words
> >alltogether because IM is just one possible use of XMPP/Jabber.
> 
> One could argue that, but one would also be wrong :)
> 
> Any protocol can be repurposed.  Just look at some of the ridiculous 
> things being done with HTTP that are not at all related to the dubious 
> heading of "hypertext", which is what "web" originally meant.  Or, 
> consider how many proprietary ad-hoc systems use IRC as a message 
> transport or router.  Nevertheless, we classify these protocols 
> according to their original intentions; IRC is not going into 
> Twisted.ORB any time soon.

I can see your point and understand that people thinking of Jabber
believe it must be in Words, but my initial remark on it not belonging
there has more to do with that most of the current code doesn't belong
where it is now.

Yes, Jabber was originally designed for chat. I'd like to give a little
bit of background to let you see where I'm coming from, and then giving
my view about how the current organisation is not ideal. I hope you'll
forgive me for the length of it.

Since Jabber came to live back in 1999, much has changed. The base
protocols have been revised and transformed into 2 RFCs:

XMPP Core defines all basics about setting up an XML Stream using the
default binding to TCP, channel encryption using TLS, authentication
using SASL, the binding of a so-called 'resource' to a stream, the basic
semantics of XML Stanzas (<message/>, <iq/> and <presence/> in whatever
is the default namespace of the stream), a number of stream and stanza
error conditions and finally the stringprep profiles for Jabber IDs.

XMPP IM defines the core features for implementing Instant Messaging and
Presence applications. This is where the server-to-server namespace and
client-to-server namespace are defined for what is traditionally known
as Jabber, all on top of XMPP Core. It defines what the XML Stanzas in
these namespaces mean exactly and how they should be handled by servers
and clients, what rosters (buddy lists) are and how entities can block
selected communications.

Then, the Jabber Software Foundation (JSF) defines a set of Jabber
Enhancement Proposals. This set of documents, that started long before
the IETF XMPP Workgroup was formed, defines additional protocols and
best-practices on top of Jabber. Some assume XMPP IM as an environment,
some only require XMPP Core. Examples range from multi-user-chat,
sending XHTML messages and doing file transfers (all IM) to more general
protocol additions like service discovery, publish-subscribe and a HTTP
binding for XML Streams (as opposed to TCP).

In Twisted, the current implementation of what is called Jabber is split
between twisted.xish.xmlstream and twisted.words.protocols.jabber. In
xmlstream, the basic concept of an XML stream is covered, and hooks for
doing any kind of stream authentication. Everything else is in the
jabber module.

The jabber module only supports the legacy authentication method (not
XMPP!) for setting up client-to-server connections (client side only),
and there is no support for TLS, SASL or even error conditions. Recently
I did implement XMPP stringprep profiles, though. The client module also
has a raw implementation of abstracting the <iq/> stanza, by allowing
you to wait for the response to a query. Higher level support for the
other two stanzas, roster handling or blocking communication is not
there. There is also a framework for building server-side components,
but that is defined in a JEP, not by XMPP.

My feeling is that the current implementation needs a lot of work, and
I'd like to split that between implementing XMPP Core and XMPP IM. I
could agree that the latter would belong in Words, but the former
doesn't and that means that most of what is currently in Words needs to
go to somewhere else. Maybe that somewhere-else is xish, but I didn't
really like the moving xmlstream there, either. Maybe it'd be good to
have a new twisted subproject XMPP that implements XMPP Core, and moving
xmlstream there.

There is no support for server-to-server connections and the server side
of client-to-server and server component connections, yet. Having that,
would be really great, though.

While writing this, I decided I'd like to work on all this and help is
of course appreciated.

Thanks for your patience,

-- 
Groetjes,

ralphm




More information about the Twisted-Python mailing list