[Standards-JIG] XMPP bandwidth compression
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: <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