[Standards] certification etc.
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