[Standards] Binary data over XMPP

Rachel Blackman rcb at ceruleanstudios.com
Wed Nov 7 18:16:14 UTC 2007


On Nov 7, 2007, at 10:00 AM, Michal 'vorner' Vaner wrote:

> Sure it is not optimal. I was just wondering, how far we want to go in
> solving it - how bug the problem is. I still think redefining XMMP  
> from
> the ground because of this is not the right way.

+1.  Throwing out the underlying XMPP-ness of XMPP seems the wrong  
approach here to me.  Or if we do, we need to immediately go, okay,  
this is no longer XMPP as you know it and make a concerted effort.

Alternatively, if we have decided that sending 100k custom emoticons  
over mobile phones generates 33k of 'needless' traffic which is a deal- 
breaker to the point that solution is throwing out XMPP 1.0 and  
starting over with 2.0, I would say that the more practical solution  
here is not to support custom emoticons on mobile phones.

About the only situation I can see for a mobile phone to be sending a  
binary file inline is if you have just taken a picture with your  
cellphone camera and want to send it to a contact in an <img/> tag.   
Which is a useful situation, but not one where I expect BASE64 use  
would be a deal-breaker, as it is not like you will be getting 14  
inline images per IM session, generally.  Unlike the 'custom emoticon'  
use case mentioned earlier.

I just think we may be overthinking this.  If things go through the  
server, they're safely XML enclosed.  If you want to send raw binary  
data without escaping it, we have at least two methods to negotiate  
client-to-client streams: Jingle and the somewhat more retro stream  
initiation.  Yes, that leaves you a bit out in the cold if you are  
behind some firewall and XMPP is your only tunnel to the outside  
world, but then you have IBB (and 33k should not be a deal-breaker in  
that case, I would think, since you are not on a cellular bandwidth  
plan).

I'm just not convinced this is a problem which doesn't already have  
multiple available solutions, much less one severe enough to require  
throwing out the underlying stream definition and starting over. :)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list