[Standards] certification etc.

Rachel Blackman rcb at ceruleanstudios.com
Tue Mar 27 22:32:05 UTC 2007

> One is that Basic defines things that are fundamental -- so far,  
> that means stream-level stuff and service discovery. It seems to me  
> that stream compression is a stream-level feature and thus it  
> belongs in the Basic suite. Naturally you can do stream compression  
> via TLS if it is supported in your SSL library. So it is preferred  
> to handle stream compression that way. If your SSL library doesn't  
> support the TLS bit for stream compression, file a bug report.

To rephrase my earlier comment, I think stream compression can be a  
recommended feature client-side, but should never be a required one.

I DO think it should be a required one, server-side!  But for  
clients, it's sort of redundant if you can support TLS.  With  
servers... well, if the server doesn't support it, the client can't  
take advantage of it.  And if the client can't take advantage of it,  
there's going to be little impetus to implement anything.  And I'm  
fine with it being a required feature in the basic specification for  
servers, rather than intermediate; it /is/ a stream level feature and  
may belong there.

Either way, it definitely should be SOMEWHERE in the server  
requirements, otherwise it's useless to the clients that /do/ need  
it.  I just think it's silly to require it for clients in general,  
when only a few really need it; the vast majority of clients will be  
speaking TLS (which I believe is *also* a server certification  
requirement, so the servers will by definition support it!) and will  
never use the stream compression.

If it's required, heck, I'll support it, but I just think it's sort  
of silly in the client spec, and clutters the requirements list. :)

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

More information about the Standards mailing list