[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
authentication/encryption)
But judging by the 'passionate' debate around the subject, I'd rather let
the thread cool down a little before going further :)

Jean-Louis  

-----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

+1

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

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
wrote:
> > 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
some
> > communication chip that most programming language cannot reach.
> >
> > In such situation, it may just be more practical to only implement a
stream
> > compression, as ZIP libraries are more readily available.
> >
> > Just by its very nature of a text representation, XML lend itself well
to
> > compression. As Joe Hildebrand hinted, our server can be set-up to use
on
> > the fly ZIP compression on c2s or s2s connections with good results.
Because
> > of the lack of 'feature' advertising it is still considered
'proprietary',
> > 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
about
> > trying to minimize the size of the XML payload as much as possible. I
would
> > only point out that using slightly shorter namespaces would definitively
go
> > 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
continuing
> the use of http:// style namespaces. Also, I would want to discourage
designing
> protocols with element names that are shortened as 'compression'. This
makes
> 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