Dirk Meyer <[EMAIL PROTECTED]> wrote: > Yes. If we only have IBB it will be Base64. Jingle will try to use > something else but it may not be possible. I see no way around this > problem, not matter what encryption we use. ESessions also use Base64, > with Jingle-Streams we have at least a chance not to.
Yeah, but we don't have a stream that is base64 encoded in a stream. Anyway, what if the server administrator has banned IBB and I'm behind a NAT? Then I'm pretty much boned. And I *DON'T* want IBB on my server for Jingle, I never want a video or file transfered in-band! So when I disable IBB Jingle, I also disable encryption. This gives an all or nothing situation, which sucks. I suggest to not use IBB, but have something like: <message to='foo' type='chat'> <body>This message is encrypted. If you see this text, something went wrong</body> <encryped xmlns='to_be_decided_on'>base64encoded data</encrypted> </message> That way, we can catch errors like a message was sent to the wrong resource, which doesn't support encryption etc. We already had problems like this when we implemented ESessions in Gajim and thus we act a little different than the standard. -- Jonathan
signature.asc
Description: PGP signature
