[Standards] certification etc.

[Fletcher, Boyd C. CIV US USJFCOM JFL J9935]

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.

boyd



-----Original Message-----
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/