<abstract>This specification defines an XMPP protocol extension that enables any two entities to establish a one-to-one bytestream between themselves, where the data is broken down into smaller chunks and transported in-band over XMPP.</abstract>
<p>This document describes In-Band Bytestreams (or IBB), a reliable bytestream protocol between two Jabber entities over a Jabber XML stream. The basic idea is that binary data is encoded as Base64 and transferred over the Jabber network.</p>
<p>IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. And, while it is mostly intended as a fallback in situations where a &xep0065; is unavailable, IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.</p>
<p>This asks Juliet if she would like to form an In-Band Bytestreams connection, using the session ID 'i781hf64' (generated by the initiator here) to uniquely reference the bytestream. The 'block-size' attribute specifies the maximum amount of data (in bytes) that an IBB packet may contain.</p>
<p>Each chunk of data is contained in a <data/> element qualified by the 'http://jabber.org/protocol/ibb' namespace. The data element SHOULD be sent in an IQ stanza to enable proper tracking and throttling, but MAY be sent in a message stanza (although this is not encouraged). The data to be sent, prior to any encoding or wrapping in the stanza, must be no larger than the 'block-size' determined in the stream negotiation.</p>
<p>The data to send is included as XML character data of the <data/> element after being encoded as Base64 as specified in Section 4 of &rfc4648;. The 'seq' attribute is a 16-bit unsigned integer counter starting at 0, and MUST be incremented for each packet sent. Thus, the next packet sent should have a 'seq' of 1, the one after that with a 'seq' of 2, and so on. The counter loops at maximum, so after value 65535, 'seq' MUST start again at 0.</p>
<p>In the case of IQ stanzas, the recipient MUST reply to each data packet with an IQ of type 'result'.</p>
<examplecaption='Acknowledging data using IQ'><![CDATA[
<iqfrom='juliet@capulet.com/balcony'
id='kr91n475'
to='romeo@montague.net/orchard'
type='result'/>
]]></example>
<p>The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.</p>
<p>It is possible that delivery of the stanza might fail.</p>
<examplecaption='Failed delivery with iq'><