[Standards-JIG] Stream Compression; was: JEP-0060: Comments on latest draft.

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Jun 30 09:36:11 UTC 2004

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.



More information about the Standards mailing list