On Tue Nov 6 10:09:41 2007, Michal 'vorner' Vaner wrote:
Because the FTP data channel (not to mention it offers passive
transfer,
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
from
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
data?
And is it possible to map normal XML <-> binary XML one to one? If
so,
we could have a stream feature "use binary XML instead and transfer
blob
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
be
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
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
