On Thu, Apr 27, 2006 at 07:34:21PM +0200, Matthias Wimmer wrote: > Peter Saint-Andre schrieb: > >Stream compression is negotiated when you can't set the TLS > >compression bit for whatever reason. I'd agree with Ralph that > >negotiating this after TLS and before SASL (or jabber:iq:auth) makes > >the most sense. So: > > > >1. TLS > >2. Stream compression > >3. SASL etc. (or jabber:iq:auth) > > I think stream compression should be negotiated AFTER doing SASL. The > reason is that some SASL mechanisms can establish an encryption layer. > If SASL encrypts the stream, stream compression would not work anymore. > Negotiating stream compression after doing SASL would result in being > the stream first compressed and encrypted afterwards - which works. >
Well, as I know, the compression can be done in TLS, not SASL. SASL is only few stanzas at the beginning to send a password, whilest the whole stream is piped trough the TLS only usually, right? And it is a good place for it anyway, as encryption makes the data look more unpredictable, which is good for encryption. I'm not expert for either of them, but I guess compresion in TLS makes sence, in SASL doesn't.. -- NAT should extinkt like dinosaurs did. Michal "vorner" Vaner
pgpc1575tbgLX.pgp
Description: PGP signature
