[Standards-JIG] JEP-0138 Compression Enhancements
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.
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>
> > 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