[Standards-JIG] XMPP bandwidth compression

Joe Hildebrand hildjj at gmail.com
Thu Jul 1 17:57:46 UTC 2004


> 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