[Standards] Binary data over XMPP

Peter Saint-Andre stpeter at stpeter.im
Wed Nov 7 09:27:49 UTC 2007

Dave Cridland wrote:
> On Mon Nov  5 15:11:33 2007, Thomas Charron wrote:
>> On 11/5/07, Michal 'vorner' Vaner <vorner at ucw.cz> wrote:
>> > Hello
>> > On Mon, Nov 05, 2007 at 02:45:05PM +0000, Dave Cridland wrote:
>> > > 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.
>> > Or make the connection blobs by default, and some blobs could contain
>> > complete XML documents, like this:
>> > lenght of first block
>> > <message to='bla'....>
>> > length of second block
>> > <iq ...>
>> > length of third block
>> > some binary data.
>> > It is as much drastic approach as the blobs, it changes the protocol
>> > from the very basic ground. Furthermore, you can extract the stanza and
>> > feed it to any XML parser.
>>   Not to mention the documentation would be much easier.  We could
>> just refer to the BEEP standards instead of having to write our own.
>> Of course, one could argue, just use BEEP at that point.
> Way ahead of you. See the first paragraph of the mail quoted above. :-)
> The essential principle is much the same, but I'm not advocating
> bringing the whole of BEEP into play, here. That has flow-control and
> all sorts, and supports the splitting of a message into multiple frames,
> which brings in a lot of complexity.
> This complexity is unwarranted, in my opinion, in the context of XMPP.
> The one thing we might want - and I stress might - is the framing of
> arbitrary data by framing everything.
> We've always relied, in XMPP, on the implicit framing that XML can give
> us, but that's not always the best option, as we've seen. Base64 doesn't
> - in my opinion - grant us sufficient efficiency in a number of
> circumstances.
> So we need something else, and our two options boil down to either
> framing everything - the BEEP method - or an escape mechanism which is
> used to frame non-XML data - we can call this the IMAP method, since
> it's pretty similar.
> I strongly suspect, given the way the discussion is going, that we
> either have to consider framing everything - and that's a huge break
> from XMPP - or else we need an escape mechanism that works. Or, of
> course, we decide to give up and frame using XML as now, and use base64
> to cope.

As always, what are the use cases?

If XML is black-and-white, I see:

1. Include a little dab of color -- an emoticon, a PNG avatar, a
thumbnail for a file, a small inline image for whiteboarding, or
whatever (something less than 50k and perhaps less than 10k). Here
Base64 might be all we need, via data: or cid: URLs perhaps.

2. Attach a larger color sketch -- a file, the image for which a
thumbnail is a representation, or whatever (50k to 1M?). I think we use
HTTP-PUT (perhaps via WebDAV) and jabber:x:oob, with IBB as a fallback.

3. Send a huge color canvas -- a music file, a podcast, a video, or
whatever (1M+?). I don't know what we use for this.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071107/5a75c03d/attachment.bin>

More information about the Standards mailing list