[Standards] Binary data over XMPP

Robin Redeker elmex at x-paste.de
Tue Nov 6 11:15:09 UTC 2007


On Tue, Nov 06, 2007 at 10:16:19AM +0000, Dave Cridland wrote:
[.snip.]
> >  You would no longer be  able to do that with binary blobs; you  
> >would have to special-case blob  stanzas fairly heavily, since I  
> >guarantee you that if the characters  '<' or '>' appear un-escaped  
> >in the binary blob, Expat will choke and  die.
> >
> >
> Sure, but there's two options with an escaping mechanism - either  
> synchronized or non-synchronized - and they can be negotiated easily.
> 
> With a non-synch mechanism, the sender just sends out the <blob/>  
> element, then sends out the binary data, then continues with XML. It  
> can be done in a single TCP packet, but it requires that the receiver  
> processes the data into stanzas prior to processing through the XML  
> parser. Some receivers already do this, so it seems reasonable that  
> this can be an option.

Also take into account that the sender also has to customize the XML
writer to allow writing raw octets, which breaks multiple layers of nice
cosy XML abstractions. (Of course with current XMPP you already need a
XML writer that allows some customisations).

> With a synch mechanism, the sender sends out a <blob/> element, and  
> then waits. The receiver then says it's ready for binary data  
> (sending a stanza to indicate this), and the sender then sends the  
> binary data - followed immediately by more XML as required, since a  
> "binary parser" is going to be octet counting anyway. For people who  
> parse all the network traffic at once through a SAX-like parser, this  
> should work fine, at the expense of some efficiency.
> 
> Note that anyone can send non-synchronized blobs, but not everyone  
> can receive them, so a client (for instance) which is built to stream  
> network data directly into a SAX parser can still *send* blobs  
> efficiently.

How do you propose the receiver determines the end of the binary data?
Is it going to be prefixed by a lenght?

Generally: pumping binary crap through XMPP is another big step _away_
from XML compatibility.

Also transforming a stream (TLS) into packets (stanzas) which are used to
again emulate a stream (TLS) sounds crazy to me anyway :)

To encrypt stanzas (packets) with TLS (stream encryption)... *shudder* :)

Robin



More information about the Standards mailing list