[Standards] Binary data over XMPP
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
> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards