[Standards] Binary data over XMPP
dave at cridland.net
Tue Nov 6 10:23:46 UTC 2007
On Tue Nov 6 10:09:41 2007, Michal 'vorner' Vaner wrote:
> Because the FTP data channel (not to mention it offers passive
> too) is _inbound_.
Well, PASV initiated connections are client->server, whereas PORT
intiated are server->client callbacks. PORT is *almost* dead, now, as
a result of the complexities of running an ALG in the firewall.
> If you opened not one TCP connection to the server,
> but two, one for XML and one for blobs, how it would be different
> single TCP connection?
Well, to state the obvious, it's not a *single* TCP connection.
There's still a distinct increase in attack surface by trying to
ensure that two connections are assuredly the same client. In
addition, you've got to synchronize the blobs on one session with the
XML on the other. I think this would get complicated fast.
> But a different question - is binary XML able to transfer binary
> And is it possible to map normal XML <-> binary XML one to one? If
> we could have a stream feature "use binary XML instead and transfer
> elements not-base64-encoded" or something like that. If the server
> needed to push it to a non-binary stream, it would have to base64
> it (or
> something like that).
> Does it make sense? (Just an crazy idea, I do not know, if it could
> of any use).
I don't know the binary XML representations very well, but it's
certainly something I'd be curious about.
One thing of note, though - the bulk of XMPP traffic *now* is not
binary. We want this to change - or at least, we want this to be able
to change - without penalty. So a binary XML format would have to
maintain near-equal efficiency when used for traditional XMPP
traffic, and in addition be a simple upgrade for implementors.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards