[Standards-JIG] JEP-0138 Compression Enhancements

JD Conley jd.conley at coversant.net
Tue Mar 1 05:43:06 UTC 2005


JEP-0138 is in need of some enhancements.  There are a couple of things
that seem obvious.

1) A method of negotiation.  In battery operated clients and large
server installations tightly controlling and monitoring CPU consumption
is very important.  As such a stream initiator may wish to use a lower
compression level than is supplied by default by the receiver.  I would
propose something like the following, with the profile for each
compression method to be managed by the JSF.

-------

The protocol flow is as follows:

Example 1. Server Offers Stream Compression Feature

<stream:features>
  <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
  <compression xmlns='http://jabber.org/features/compress'>
    <method name='zlib'
profile='http://jabber.org/features/compress/zlib'/>
  </compression>
</stream:features>
    

Example 2. Client Requests Stream Compression

<compress xmlns='http://jabber.org/protocol/compress'>
  <method name='zlib'>
    <settings xmlns='http://jabber.org/features/compress/zlib'>
      <level>5</level>
    </settings>
  </method>
</compress>
    

Example 3. Server Acknowledges Stream Compression

<compressed xmlns='http://jabber.org/features/compress'/>
    
-------

The receiver would not necessarily need to use the initiator's supplied
settings; just as in resource binding the requested resource is not
necessarily used.

2) Some more error handling is needed.  For example, what happens if the
initiator sends an invalid method name?  What if the supplied settings
are invalid?  What if there is an error initiating the compressed stream
(i.e. insufficient resources of the receiver)?  Ideally this would be an
error element like SASL's failure with the ability to retry your request
without reconnecting.  This could also be accomplished with stream
errors, it should just be documented which errors are used.


JD Conley



More information about the Standards mailing list