[Standards] Binary data over XMPP

Dave Cridland dave at cridland.net
Mon Nov 5 14:45:05 UTC 2007


On Mon Nov  5 11:51:16 2007, Michal 'vorner' Vaner wrote:
> On Mon, Nov 05, 2007 at 11:40:18AM +0000, Dave Cridland wrote:
> > A new top-level stanza of (say) <blob/>, which much the same  
> attributes as > any other routable stanza, but also has an octet  
> count. Upon receipt, the > XML processing is suspended, and the  
> following octets are handled verbatim:
> >
> > <blob from='portia at example.com/court'  
> to='shylock at example.net/court' > octet-count='4'/>1234
> 
> You probably can not do that with any reasonably out-of-the-box XML
> parser. Furthermore, you may need to pass the stream trough charset
> decoder to get some internal stringish representation. This will  
> make it
> mad. So, in short, I strongly disagree here.
> 
> 
An alternate would be to encapsulate both XML and blobs, which'd be  
an even more radical departure. (And look impressively like BEEP). So  
for each chunk, you'd predefine how long it was, and whether it was  
blob or XML. (Yes, there are defined formats for doing so, which have  
been mentioned on this list before).

Or - just a thought - we could pinch IMAP's synchronizing literals:

C: <blob ... octet-count='4096' sync='true'>
S: <blob ... sync='go=ahead'>
C: [4096 octets of blob]
C: [... more XML ...]

This adds a round-trip to all blob-stanza transfers, of course.  
(Although it's a hop-by-hop RTT, not an end-to-end RTT). No reason  
that couldn't be an option, too, so implementations which can cope  
with non-synchronizing blobs can say so. (I personally suspect many  
will be able to).


> But you may like SCTP or how's the protocol called and push the  
> blobs
> out-of-the stream.

Yes, but I doubt that'd get much traction. SCTP stacks are rare  
enough, and especially so in those areas where the base64 encoding  
overhead of (say) IBB makes a serious difference. (Yes, you could  
encourage all XMPP clients to include a SCTP/UDP implementation, but  
that's a heavy requirement, I'd have thought).

>  Or another "blobby" TCP connection to the server. (if
> you really want to send these things trough the server).

Well, I think increasingly we need to send these things via the  
server. In fact, we're doing so quite a bit - the question is, do we  
care about the base64 overhead enough that we want to address this.

Another option would be to setup a distinct connection (and protocol)  
for routing blobs, and so send them through the server, yet not  
in-band. I'm not comfortable with this, because it means essentially  
duplicating all security information, and maintaining synchronization  
between two distinct streams.

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