[Standards-JIG] Re: XMPP bandwidth compression

Matthew A. Miller linuxwolf at outer-planes.net
Thu Jul 1 18:10:30 UTC 2004


I think fast-infoset should not be included here, since traditional 
compression formats will need some bounding (HTTP automatically includes 
this in its structure, and SASL specifies requirements for how this 
applies for security layers).

For the buffering problem, the format should probably apply regardless 
of the actual compression method in use.  SASL does this by requiring 
the first four bytes of every transmission to be the (network-ordered) 
integer size of the current chunk of secured data.  I think we should do 
something similar.  If we want to apply fast-infoset to an XMPP stream, 
it should probably be a separate feature altogether.

Just my op-ed (-:


-  LW

Joe Hildebrand wrote:
>>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.
> 




More information about the Standards mailing list