[Standards-JIG] JEP-0138 Compression Enhancements

Joe Hildebrand hildjj at gmail.com
Sun Mar 6 20:43:34 UTC 2005


Does the server need to know what level of compression the client is
sending?  My understanding of glib is that the compressor specifies
the compression level.  Now, there may be other things that need to be
negotiated, in which case, the server should offer choices, and the
client should pick from those choices.

You are right, there need to be more error conditions specified.


On Mon, 28 Feb 2005 21:43:06 -0800, JD Conley <jd.conley at coversant.net> wrote:
> 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
> 


-- 
Joe Hildebrand



More information about the Standards mailing list