[Standards] Binary data over XMPP

Dave Cridland dave at cridland.net
Fri Nov 9 23:35:13 UTC 2007


On Fri Nov  9 18:37:08 2007, Rachel Blackman wrote:
> If we like to chant the 'XMPP is not really XML' mantra and the 'we  
>  must shave off every byte we can to spare the poor mobile users'   
> mantras, that's great.

I'm not chanting any mantras, sorry. If encrypted sessions become the  
rule, rather than the rare exception - and I do want this to happen -  
then 25% of a server owner's bandwidth bill is going to be down to  
base64. If you're okay with that, please send me the cash instead. :-)

>   But considering we only have 3 actual main  stanza types, a  
> purely binary (and not necessarily XML-related)  protocol would be  
> more efficient.

Much harder to code and debug, though - we need a middle ground here.  
An escape mechanism makes sense to me, but I'm easy to persuade  
otherwise.

>   And if we're going to break the  world by changing how XMPP  
> parsing works, then why on earth would we  go through the pain of  
> breaking our protocol to glue the ability to  include a few extra  
> characters in just to go ASCII85 or BASE91 instead  of BASE64?
> 
> 
This I definitely agree with, not least because it still doesn't gain  
us anything particularly useful in terms of bandwidth improvements.  
We might drop that overhead from 33% to 10% with a serious amount of  
work, but that's as good as it gets, and means introducing  
tricky-to-write untested codecs everywhere. Fun and games.


> I think we've lost sight of whatever the original problem we were   
> trying to solve was (inline images?  Size of binary blobs to  
> mobiles?)  and have become caught up in hypothetical solutions  
> which may no  longer be directly connected to the issue.  :)

The problem is hypothetical, which makes solutions also hypothetical.

The hypothesis is:

XMPP will display a tendency toward being used increasingly for  
binary data, in particular via encryption, but also for various other  
things (including file transfer). As this trend continues, the issue  
of base64 encoding will play a significant role in bandwidth figures  
for both servers and clients. This trend is desirable, because it  
indicates an uptake of encryption, and therefore is to be encouraged  
by support within the protocol.

Inlined images aren't driving this for me at all. At best it seems  
that addressing these if we can has merit. I'm really thinking in  
terms of IBB, and leveraging that for use in encrypted session  
support et al ready for the future when we'll actually need this.

I'm entirely cool with agreeing it's not needed now, but the sooner  
we start thinking about this the better - I think you're clearly  
stating that if we choose to address this, it'll be a major bit of  
work.

Please don't consider this in terms of inlined images and fringe  
users - think of it in terms of ubiquitous encryption and servers.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list