[Standards-JIG] Stream Compression

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Fri Jul 2 15:53:54 UTC 2004

Well, to answer the request for information, we are using a socket level
compression, i.e. outside any application level control, pretty much along
the way SSL/TLS is implemented in Java. As a reference, you may want to have
a look at an open source implementation available at jemos.org. It does the
same thing. From an application perspective it is completely transparent,
and is also outside the specification reach of XMPP. This is why I call it
'proprietary' although it uses well known techniques.

As I said, the advantage comes from not being tied up to any XML compression
standard in the work, and using available libraries.

If we were to propose a mechanism to incorporate the compression feature in
the XMPP stream, I would be inclined to use something along the lines of
STARTLS mechanism (after all this is compression without
But judging by the 'passionate' debate around the subject, I'd rather let
the thread cool down a little before going further :)


-----Original Message-----

Message: 5
Date: Wed, 30 Jun 2004 10:49:52 -0600
From: Joe Hildebrand <hildjj at gmail.com>
Subject: Re: [Standards-JIG] Stream Compression;	was: JEP-0060:
	Comments on latest draft.
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <82777bea04063009494e944894 at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII


It also makes the protocol much more *safely* extensible for private

On Wed, 30 Jun 2004 11:36:11 +0200, Ralph Meijer
<jabber.org at ralphm.ik.nu> wrote:
> On Wed, Jun 30, 2004 at 05:19:23AM -0400, Jean-Louis Seguineau/EXC/ENG
> > AFAIN having TLS implies to use a crypto provider on the target
platform. On
> > many small foot print devices this is either not available or buried in
> > communication chip that most programming language cannot reach.
> >
> > In such situation, it may just be more practical to only implement a
> > compression, as ZIP libraries are more readily available.
> >
> > Just by its very nature of a text representation, XML lend itself well
> > compression. As Joe Hildebrand hinted, our server can be set-up to use
> > the fly ZIP compression on c2s or s2s connections with good results.
> > of the lack of 'feature' advertising it is still considered
> > but I do not see why it could not be extended to everybody's use.
> >
> > Jean-Louis
> >
> > P.S. On a more general stand, I have seen good remarks on this thread
> > trying to minimize the size of the XML payload as much as possible. I
> > only point out that using slightly shorter namespaces would definitively
> > in the right direction, as this would decrease EVERY stanza's size
> > accordingly, not just one of them once and a while :)
> >
> > I there a valid requirement to use http://jabber.org/protocol/muc (30
> > characters) instead of for example xmpp:muc (8 characters) ?
> If gzip compression is a viable option for small foot print devices, and
> TLS compression can be used on others, I would want to plead for
> the use of http:// style namespaces. Also, I would want to discourage
> protocols with element names that are shortened as 'compression'. This
> the protocol much more readable.
> --
> Groetjes,
> Ralphm
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig

Joe Hildebrand

More information about the Standards mailing list