[Standards] certification etc.

Rachel Blackman rcb at ceruleanstudios.com
Wed Mar 28 04:47:25 UTC 2007


> The consensus of those posting on the list so far seems to be for  
> making stream compression recommended (or possibly required) for  
> servers in Basic. But further discussion will lead to  
> enlightenment, I presume.

Correct.  My thought is that servers /must/ support stream  
compression (otherwise it is useless to clients). It doesn't matter  
what client I use if jabber.org doesn't support stream compression,  
in other words.  Compression is useless without server support.

Client support, however, could really vary.  In a number of cases,  
stream compression is like trying to glue a spoiler onto a horse...  
no matter what I might dress my beloved dope of a thoroughbred  
gelding up as, I know he's never going to win a street race against a  
Ferrari.  And that's fine; even if both horses and cars are forms of  
transportation, they're used in different ways, and one is not  
necessarily useful where the other would be.  My horse may not be  
able to do 0-60 in 2 seconds, but I'm pretty sure a Ferrari can't  
jump a four-foot fence.

It seems to me that it's much the same with Zlib versus TLS... they  
may do some of the same things, but they're useful in entirely  
different areas.  Thus, I don't think it's worthwhile to necessarily  
require stream compression in Basic or Intermediate client specs.  :)

This isn't to say there aren't places where stream compression isn't  
useful, or even perhaps vital.  Maybe there should be an 'XMPP  
Bandwidth-Minimal Client' specification, for mobile or severely- 
bandwidth-limited situations?  In such a case I can absolutely see  
stream compression being required, and where in fact TLS/SSL might be  
entirely optional.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list