[Standards-JIG] XMPP bandwidth compression
jean-louis.seguineau at antepo.com
Sat Jul 3 16:47:55 UTC 2004
IMHO this bodes perfectly with the way XMPP is shaping up at the IETF. This
goes along the lines of the idea I had using a trigger similar to STARTLS.
Although the explanations provided in this thread are all very enlightening
on describing the great XML futures lying in front of us, I believe their
implementation and mainstream usage may be a little far away. Some of us may
have to solve immediately some tangible issues in the mean time...
As a comment, may I add that most of the discussion so far has been very
server centric. I mean that all use cases for 'in XML compression' seemed to
point to a need for the stream to be entirely decoded by the receiving
entity (which is OK for a server but may not be true for an XMPP routing
Date: Thu, 1 Jul 2004 11:57:46 -0600
From: Joe Hildebrand <hildjj at gmail.com>
Subject: Re: [Standards-JIG] XMPP bandwidth compression
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <82777bea040701105764ec028 at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
> You could still solve both in the same solution. The problem right now is
> that XMPP XML-streams are just opened without any negotiation wich method
> to use to transport them. (The only thing both sides can do is detect wich
> encoding either side is trying to use, there isn't a way to find out wich
> are and aren't supported either).
There are multiple ways of doing this. Here's the one I'm proposing,
which is a little more XMPP-like:
S: <compression xmlns='urn:ietf:params:xml:ns:xmpp-compression'>
S: <method maxbuffer='1024'>gzip</method>
C: <compress xmlns='urn:ietf:params:xml:ns:xmpp-compression'>
C: <method buffer='256'>gzip</method>
S: <compressed xmlns='urn:ietf:params:xml:ns:xmpp-compression' />
and then a new stream would be negotiated in the compressed world.
According to linuxwolf, many of these methods would require a buffer
size negotiation, hence the maxbuffer/buffer attributes.
This would probably be best as a new IETF I-D, with IANA maintaining
the list of compression methods. I'd be ok with it being a JEP, with
an http://jabber.org namespace, and the Jabber Registrar maintaining
the list of methods. Either way, the I-D/JEP would probably specify a
small number of compression methods, and new I-Ds/JEPs would be
written to add new ones.
More information about the Standards