[Standards-JIG] XMPP bandwidth compression

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Mon Jul 5 10:30:42 UTC 2004

Bob, I sincerely believe you have been a great contributor and an invaluable
source of information about the genesis of these contending technologies.
There is matter here for everybody to form a well documented opinion on the

AFAIAC being of a pragmatic nature, and more geared to using the
technologies that to pursue long academic studies, I will lay down a few
facts that may help:

1/ We have implemented multi-tiered XMPP servers build around a traditional
access/routing/management architecture. The largest installation have reach
the HW limits and were handling 500K concurrent users doing what we believe
is an average IM traffic (a message every 3s, plus the odd presence changes,
plus the login/logout) We haven't had to use compression to handle the
generated traffic between the component of the system.

2/ ASN.1 has been around for a long time, 15 Years you said, and yet has not
been widely used except in a few well identified fields (LDAP, X509, some
SMSC access protocols to present some). My opinion is that ASN.1 is the
typical example of a passionate subject in an entrenched community. And to
say the least, unless within a very small group of bright and talented
individuals enjoying doing direct mental deciphering, it his not widely
practiced by the vast community of internet technology developers (I am part
of them...) What's make XMPP enjoyable is that it provides an easy
visualization of your concepts. That the beauty of XML, people understand
because they can visualize (It's a one pass mapping) and this is not going
to go away soon.

3/ There has been so much hype around XML, that doing anything else does not
make sense commercially these days. (I know this is a bad reason for an open
source community, but one has to live :) Funnily enough, customers and
prospects in a large part of the IT community understand XML, I am not
convinced this is true for ASN.1. But they even understand better HTTP, this
is why we keep repeating the same story about the advantages of XMPP....

IMHO your description of the state of these technologies, mixed with some of
the facts above, as well as the thread about PubSub make me believe that:

1/ We have not yet reached a real need for XMMP stream compression, at least
on the very high systems.

2/ If need be, we have some technologies at hand that can be applied
immediately and if the JSF want to spend some time laying a version 1
framework for it, the proposal should be aligned with the current XMPP best
practices as standardized at the IETF (see Joe's approach for this)

3/ That the reasonable concerns expressed in this forum about the increased
size of the payload generated by new areas of development such as PubSub
must be addressed so that everyone feels comfortable implementing or using
them. Having as many options to choose from before getting to a consensus is
probably the best approach for this, isn't it ?

On that last point, which is outside the direct concern of XMPP stream
compression, I am still very interested in understanding you views about the
efficiency of stanza's parsing following what I expressed in one of my
recent posts.


More information about the Standards mailing list