Stream feature negotiation ordering. Was: Re: [jdev] S2S questions - from attribute and version support
Michal vorner Vaner
michal.vaner at kdemail.net
Thu Apr 27 12:51:32 CDT 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the JDev