[Standards-JIG] JEP-0138 Compression Enhancements

Stephen Pendleton spendleton at movsoftware.com
Thu Mar 10 21:48:37 UTC 2005


I accidentally posted this to jdev, but it belongs here:

After reading through the JEP-0138, I would like to submit some ideas on
this to the dev community.  As was mentioned before on the list many mobile
clients have limited processing and/or memory requirements that may preclude
the use of zlib at certain compression levels. For example, zlib compression
at level 3 may perform well on a typical cellphone, but level 9 may produce
unacceptable performance. It seems to me that this would be a excellent use
case of JEP-0020 (feature negotiation) to find out what compression levels
and/or methods (zlib, bzip, foozip, etc) are supported on the endpoints.

A sample session is described below:

CLIENT (query server for features):
<iq
    type='get'
    from='juliet at capulet.com/imov'
    to='movcast.movsoftware.com'
    id='neg1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

SERVER (sends back a negotiable feature list):
<iq
    type='result'
    from='movcast.movsoftware.com'
    to='juliet at capulet.com/imov'
    id='neg1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/feature-neg'/>
    <feature var='zlib-compression-level'/>
    ...
  </query>
</iq>

CLIENT (asks to negotiate zlib type compression):
<iq
    type='get'
    from='juliet at capulet.com/imov'
    to='movcast.movsoftware.com'
    id='neg2'>
  <query xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='zlib-compression-level'/>
    </x>
  </query>
</iq>

SERVER (server supports both levels 1 and 2 of the zlib compression
protocol): <iq
    type='result'
    from='movcast.movsoftware.com'
    to='juliet at capulet.com/imov'
    id='neg2'>
  <query xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='zlib-compression-level' type='form'>
        <option><value>1</value></option>
        <option><value>2</value></option>
      </field>
    </x>
  </query>
</iq>


CLIENT (the client selects level 2 of zlib compression):
<iq type="result" id="1" to='movcast.movsoftware.com'>
  <query xmlns="http://jabber.org/protocol/feature-neg">
    <x xmlns="jabber:x:data">
      <field var='zlib-compression-level'>
        <value>2</value>
      </field>    
    </x>
  </query>
</iq>

CLIENT (the client must now initiate a new stream using the new compression)
<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='movcast.movsoftware.com'>

Any feedback on this scheme would be welcome.

-----Original Message-----
From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of JD Conley
Sent: Tuesday, March 01, 2005 12:43 AM
To: Jabber protocol discussion list
Subject: [Standards-JIG] JEP-0138 Compression Enhancements


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
_______________________________________________
Standards-JIG mailing list
Standards-JIG at jabber.org
http://mail.jabber.org/mailman/listinfo/standards-jig






More information about the Standards mailing list