[Standards-JIG] XMPP bandwidth compression

Jean-Louis Seguineau/EXC/ENG 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


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

Message: 4
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: <stream:features>
S:  <compression xmlns='urn:ietf:params:xml:ns:xmpp-compression'>
S:    <method maxbuffer='1024'>gzip</method>
S:    <method>fast-infoset</method>
S:  </compression>
S: </stream:features>

C: <compress xmlns='urn:ietf:params:xml:ns:xmpp-compression'>
C:   <method buffer='256'>gzip</method>
C: </compress>

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.

Joe Hildebrand

More information about the Standards mailing list