[Standards-JIG] JEP-0138 Compression Enhancements

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Sun Mar 6 21:31:07 UTC 2005


I think the idea is to tell the server what compression level to use, which 
the client wouldn't otherwise have control over.

-Justin

On Sunday 06 March 2005 12:43 pm, Joe Hildebrand wrote:
> 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



More information about the Standards mailing list