> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jonathan Schleifer > Sent: Wednesday, August 20, 2008 5:12 PM > To: [email protected] > Subject: Re: [Security] TLS Certificates Verification > > Dirk Meyer <[EMAIL PROTECTED]> wrote: > > 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.
In band bytestreams means that the streams occur in the original jabber stream itself. If your admin has banned IBB, he _really_ means to say that he has banned XMPP. You will be boned long before you can even contemplate about whether or not to set up IBB or ESessions. <http://www.xmpp.org/extensions/xep-0047.html> Now if your admin blocks inbound connections you can still connect 'inside' the existing XMPP via IBB. If he hasn't you can connect via Jingle/ICE/SIP/whatever and do P2P XMPP and not be bothered with B64. > 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> > You are pretty much describing IBB. Having an actual message is a moot point. The users would have set up ESessions or IBB which means they both support it. If they don't both support it, the whole process will break long before they get to use IBB or ESessions. Having it in a message stanza makes no sense. Unfortunately these technologies mean that both users need to be online while communicating. If the message is kept on the server because the destination is offline, he will get it when he comes online but it will have no context. The stanza that dictates (generally) deliver or fail, is IQ. That is what is used in IBB. > > We already had problems like this when we implemented ESessions in > Gajim and thus we act a little different than the standard. > > -- > Jonathan
