[Standards] certification etc.
Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Boyd.Fletcher at je.jfcom.mil
Wed Mar 28 02:58:39 UTC 2007
there are several reasons why stream compression is a better approach that TLS:
1) TLS with compression uses much more bandwidth that XMPP with just stream compression
2) With TLS compression you can use something like the new Efficient XML spec coming out of the W3.org which is better than zlib (and faster!)
3) in many environments (particularly with SATCOM), the TLS connect/reconnect costs are simply to expensive.
thus stream compression should be required for client and servers in the intermediate specfiication.
From: standards-bounces at xmpp.org on behalf of Rachel Blackman
Sent: Tue 3/27/07 6:32 PM
To: XMPP Extension Discussion List
Subject: Re: [Standards] certification etc.
> 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